Re: [Xen-devel] [V10 PATCH 0/4] pvh dom0 patches...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.05.14 at 03:00, <mukesh.rathor@xxxxxxxxxx> wrote:
> As Konrad points out, there are other issues with that part of the code.
> So, IMO, we should wait and address that altogether for both PV and PVH,
> and for now leave this as is.

I'm fine either way, as long as you and Roger can reach agreement.
I still tend towards considering Roger's position the right one as a
mid/long term route.

> If you still feel we should do this in xen (as in required for this
> patch series to go in), then we'd need to communicate last pfn to guest.
> However, note that guest would still have all that code for PV, for pvh
> we'd just skip it. Obvious way coming to mind is:
> 
> unsigned long last_pfn_mapped; 
> 
> added to struct start_info.  Alternative would be to add a 
> new sub call to perhaps getdomaininfo hcall or something similar. 
> Please lmk. 

We already have the max_pfn field in the shared info, which for
PV is under the sole control of the guest kernel. That could
certainly be set to other than zero to communicate what the
highest mapped PFN is. The problem I'm seeing with this (and
with everything you suggest above) is that this doesn't tell the
guest where the holes are - while Dom0 can get at the machine
memory map to tell (or really: guess) where they are, DomU can't
yet will need to as soon as you want to be able to support device
pass-through. Hence I guess we will need XENMEM_memory_map to
reflect reality for PVH guests.

Jan


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