[Xen-devel] RE: [PATCH][retry 2][2/2] new platform hypervisor call to get APICIDs

["Langsdorf, Mark" <mark.langsdorf@xxxxxxx>]

> > I have tested this on my 4p/16 core machine and it works.  I
> > would appreciate testing on other boxes.
> 
> This patch is much better, although unfortunately the 
> dom0_vcpus_pinned change doesn't look like it will work as-is. 

I have confidence that Keir will fix that up before he
commits the code. =)

> That is, the only failure case I see on
> the hypervisor side is if you fail copy_to_guest, so that 
> means on the dom0 side the only way you think the dom0
> vcpus are unpinned is if you have a major failure.   

Well, it was more "if there is a major failure, the
information in this array is junk anyway, so assume
we're unpinned and accept there may be errors down
the line."

> It seems you really need to worry about: a) making the
> platform op call on an HV that doesn't support it,

The case statement will handle that already.  I tested
that during my development.

> b) making the platform op call, and somehow returning
> that dom0 is unpinned,

I can add that.  Thanks.

> c) making the platform op call and
> returning that the dom0 is in fact pinned.

That's not an error.  I'm not sure what you mean.
 
> Generally, I'm not against the way you've done it here, but 
> originally I thought you would re-enable the code in dom0
> mpparse-xen.c and then just have a hypercall to determine
> whether dom0 had the vcpus pinned or not.  The advantage
> to that way is that if there is ever any other information 
> needed from the MP tables, we will just have it available
> in the dom0.

I'd rather stick with a minimal approach that does what
needs to be done to address this issue.

-Mark Langsdorf
Operating System Research Center
AMD


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel