Re: [Xen-devel] RFC: vNUMA project

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.11.14 at 14:45, <wei.liu2@xxxxxxxxxx> wrote:
> On Wed, Nov 12, 2014 at 09:35:01AM +0000, Jan Beulich wrote:
>> >>> On 11.11.14 at 19:03, <david.vrabel@xxxxxxxxxx> wrote:
>> > On 11/11/14 17:36, Wei Liu wrote:
>> >> Option #1 requires less modification to guest, because guest won't
>> >> need to switch to new hypercall. It's unclear at this point if a guest
>> >> asks to populate a gpfn that doesn't belong to any vnode, what Xen
>> >> should do about it. Should it be permissive or strict? 
>> > 
>> > There are XENMEMF flags to request exact node or not  -- leave it up to
>> > the balloon driver.  The Linux balloon driver could try exact on all
>> > nodes before falling back to permissive or just always try inexact.
>> > 
>> > Perhaps a XENMEMF_vnode bit to indicate the node is virtual?
>> 
>> Yes. The only bad thing here is that we don't currently check in the
>> hypervisor that unknown bits are zero, i.e. code using the new flag
>> will need to have a separate means to find out whether the bit is
>> supported. Not a big deal of course.
>> 
> 
> If this new bit is set and domain has vnuma, then it's valid
> (supported); otherwise it's not.
> 
> To not break existing guests, we can fall back to non-vnuma hinted
> allocation when the new bit is set and vnuma is not available.

While this is valid, none of this was my point - I was talking about a
new guest running on an older hypervisor.

Jan


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