| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: [PATCH][retry 2][2/2] new platform hypervisor call to ge
> > 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
|
|
|
| |
|
Home