RE: [Xen-devel] [PATCH 18/18] Nested Virtualization: hap-on-hap

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> On the down side, the terminology is quite confusing...

/me votes for meta-virtual to indicate a VM running in
a nest.  And meta-physical address to refer to a guest
physical address in a meta-virtual VM.


> -----Original Message-----
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Friday, April 16, 2010 10:10 AM
> To: Christoph Egger
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH 18/18] Nested Virtualization: hap-on-
> hap
> 
> Hi,
> 
> I'll start by saying that the overall design seems like a good one:
> keeping a selection of shadow p2m tables around that follow
> guest_p2m(host_p2m(l2gpa)), and updating them on demand.  I think it's
> good to start with a simple system like this one, though we might find
> that nested Xen performs poorly because of its tendency to discard
> ASIDs
> on every vcpu context switch.
> 
> On the down side, the terminology is quite confusing.  There are a few
> places where it's not clear what kind of cr3 value is meant, and I
> couldn't understand this patch at all until I saw this comment:
> 
> > +/* With nested virtualization gva == nested gpa, hence we use
> paddr_t
> > + * to not overflow. */
> 
> This is not right - the nested GPA is not a virtual address.  It's yet
> another fictional physical address.  Can you please find some better
> name for it?  At the moment you have functions called p2m_gva_to_gfn
> that don't take a GVA and don't return a GFN.
> 
> 
> Anyway, backing away from the detail of the code, I have some more
> general design questions:
> 
> - How does memory management work in general for the nested p2ms?
> - What happens if we run out of memory?
> 
> - What's the performance difference between shadow-on-HAP and HAP-on-
> HAP?
> - What's the difference if the nested hypervisor runs more than
>   MAX_NESTEDP2M VMs?
> - How was the figure for MAX_NESTEDP2M arrived at?
> 
> - What happens when the host changes the p2m table of the L1 guest?
>   Don't we need some sort of global flush of all the nested p2ms to
>   maintain isolation?  Or is it implicitly handled by existing TLB
>   shootdowns?
> 
> - You seem to have duplicated a lot of the existing p2m-building code
>   (type_to_flags, write_p2m_entry, next_level, &c).  Why is that?  I
>   thought the whole point of patches 4, 6 and 17 was so that the nested
>   p2ms could be handled with the same mechanism as normal p2ms?
> 
> Cheers,
> 
> Tim.
> 
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, XenServer Engineering
> Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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