> 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
|
Home