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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 05/08/2014 01:12 AM, 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.

Wait, which maintainers are you talking about?

One of the big long-term wins of PVH is to get rid of a lot of the cruft 
in Linux resulting from the PV interface.  "As close as possible" should 
mean that if there are several equally supportable / low-cruft ways to 
do something, do it the way PV does.  But the "as possible" escape hatch 
means that when we can reduce cruft / code required in the Linux kernel, 
we should try.

  -George

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