[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC][v3][PATCH 1/6] xen:x86: record RMRR mappings



>>> "Chen, Tiejun" <tiejun.chen@xxxxxxxxx> 08/19/14 4:28 AM >>>
>On 2014/8/19 10:14, Chen, Tiejun wrote:
> Please don't say simply that e820entry is not suitable, what's your
> preferred structure here?
>
> Looks you are saying something like,
>
> struct __packed rmrr_entry {
>      uint64_t addr;
>      uint64_t size;
> };
>
> but compare that to the existing e820entry,
>
> struct __packed e820entry {
>      uint64_t addr;
>      uint64_t size;
>      uint32_t type;
> };

struct xen_reserved_device_memory {
    xen_pfn_t pfn;
    xen_ulong_t count;
};

>Another concern is that we always use xen_memory_map for the hypercall,
>
>struct xen_memory_map {
     >/*
      >* On call the number of entries which can be stored in buffer. On
      >* return the number of entries which have been stored in
      >* buffer.
      >*/
     >unsigned int nr_entries;
>
     >/*
      >* Entries in the buffer are in the same format as returned by the
      >* BIOS INT 0x15 EAX=0xE820 call.
      >*/
     >XEN_GUEST_HANDLE(void) buffer;
>};
>
>As it comments above, theoretical e820 is expected in buffer.

That's what your patch currently does - nothing keeps you from either altering
the comment or defining a new structure (and then right away with a properly
typed handle).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.