Re: [Xen-devel] [PATCH v14 00/20] Introduce PVH domU support

[Tim Deegan <tim@xxxxxxx>]

At 17:23 +0000 on 04 Nov (1383582187), George Dunlap wrote:
> On 04/11/13 16:59, Konrad Rzeszutek Wilk wrote:
> >> This also means no support for "legacy" forced invalid ops -- only native
> >> cpuid is supported in this series.
> > OK.
> 
> (FWIW, support for legacy forced invalid ops was requested by Tim.)

I was worried about existing PV kernel code that used the fake-CPUID,
which would break if the 'core' kernel code went from PV to PVH.  But
I guess I could be convinced that such kernel code is buggy?  Really,
the high-order bit was consistency.  The version I commented on
supported them for user-space but not for kernel, which seemed like
risking trouble for no benefit.

> >>   - Interface-wise: Right now PVH is special-cased for bringing up
> >> CPUs.  Is this what we want to do going forward, or would it be better
> >> to try to make it more like PV (which was tried before and is hard), or 
> >> more
> >> like HVM (which would involve having emulated APICs, &c &c).
> > How is it hard? From the Linux standpoint it is just an hypercall?
> 
> This is my understanding of a discussion that happened between Tim and 
> Mukesh just as I was joining the conversation.  My understanding was 
> that the issue had to do with pre-loading segments and DTs, which for PV 
> guests is easy because Xen controls the tables themselves, but is harder 
> to do in a reasonable way for HVM guests because the guest controls the 
> tables.  Mukesh had initially implemented it the full PV way (or mostly 
> PV), but Tim was concerned about some kind of potential consistency 
> issue.  But I didn't read the discussion very carefully, as I was just 
> trying to get my head around the series as a whole at that time.

I don't think the PV code would be very hard.  As I said, we already
have code to load all that descriptor state for a HVM vcpu; it should
just be a question of calling it all in the right order.

Cheers,

Tim.

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