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

[David Vrabel <david.vrabel@citrix.com>]

On 08/05/14 01:12, Mukesh Rathor wrote:
> On Wed, 7 May 2014 15:38:26 +0200
> Roger Pau Monné <roger.pau@citrix.com> wrote:
> 
>> On 07/05/14 15:20, Konrad Rzeszutek Wilk wrote:
>>> For example, right now the Linux PV code can run with an E820 that
>>> looks like swiss cheese - aka like the hosts' one. That is easily
>>> seen if you boot an PV guest with PCI passthrough devices - as the
>>> libxl 'e820_host' option gets turned on which creates an E820
>>> that looks like the hosts. Granted it does not populate the P2M
>>> as such (it is all linear). But the point is that the Linux
>>> code is capable of dealing with this and bring the P2M to sync.
>>>
>>> Hoisting this up in the hypervisor would be a plus - as the
>>> Linux code wouldn't have to do this anymore.
>>
>> IMHO doing it in the hypervisor is clearly the right solution, forcing
>> the guest OS to do all this on it's own just promotes code duplication
>> across the several OSes with PV(H) support.
> 
> I am in agreement with you, but my point was code exists for PV already,
> so if you address pvh only, then that code still has to exist in 
> the guest until PV reaches EOL. 
> 
> FWIW, my agreement with previous maintainers was to keep PVH as close to 
> PV as possible.

PVH support in Linux should be in order of preference:

1. Like native.
2. Like HVM guests.
3. Like PV guests.
4. PVH specific.

In this specific case of the memory map of a PVH guest at boot it should
match the p2m (like it would for a HVM guest).

For Linux, it would be acceptable for it to be like PV as an interim
solution, but for a new guest without PV support it really doesn't want
to have to reimplement the games that Linux PV plays (it's complex and
has been historically buggy and broken in various less common corner cases).

Fixing it in Xen would be simpler too, as it wouldn't have to do the
depopulate/repopulate dance.

David

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