On Monday 13 August 2007 12:30:15 Keir Fraser wrote:
> On 13/8/07 11:02, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:
> > @@ -35,6 +35,7 @@
> > #define XENMEM_increase_reservation 0
> > #define XENMEM_decrease_reservation 1
> > #define XENMEM_populate_physmap 6
> > +#define XENMEM_DEFAULT_CPU ((unsigned int)-1)
> > struct xen_memory_reservation {
> >
> > /*
> > @@ -66,6 +67,7 @@ struct xen_memory_reservation {
> > * Unprivileged domains can specify only DOMID_SELF.
> > */
> > domid_t domid;
> > + unsigned int cpu;
> > };
>
> We cannot change the size of existing hypercall structures.
Except Xen bumps major version number to 4 ? :-)
You are worrying about PV guests that lag behind with syncing
pulic headers such as NetBSD/Xen ?
> In this case we could steal bits from address_bits field and create a pair
> of 16-bit fields from it. Also, a physical cpu id is not a great fit for
> this hypercall -- it is meaningless to most guests who do not see the
> physical cpu map.
> Better to pass a vcpu_id and let Xen work out the most appropriate physical
> cpu id based on the vcpu's affinity. Or have a concept of per-guest
> 'virtual node identifiers' and pass a 'uint16_t vnodeid'. The latter might
> actually be a nice abstraction -- it'd be good to know other people's
> thoughts on this?
Making struct xen_machphys_mapping NUMA-aware is also a no-go, right?
It would additionally need a min_mfn and a vnodeid member.
Oh, and how should the guest query how many vnode's exist?
--
AMD Saxony, Dresden, Germany
Operating System Research Center
Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
Dr. Hans-R. Deppe, Thomas McCoy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home