Re: [Xen-devel] [V3 PATCH 9/9] pvh dom0: add opt_dom0pvh to setup.c

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.11.13 at 12:54, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Wed, Nov 27, 2013 at 8:12 PM, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> 
> wrote:
>> On Wed, 27 Nov 2013 15:00:43 +0000
>> George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>
>>> On 11/27/2013 02:27 AM, Mukesh Rathor wrote:
>>> > Add opt_dom0pvh. Note, pvh dom0 is disabled until the fixme in
>>> > domain_build.c is resolved. The fixme is added by patch title:
>>> > "PVH dom0: construct_dom0 changes"
>>>
>>> So it's been asked before but I haven't seen an answer yet: What
>>> exactly is the problem here, and when might it be fixed?
>>
>> The problem would happen if an mmio space sits above the highest
>> e820 address. Ie, the e820 didn't report it. FWIW, PV linux would not
>> boot as dom0 in those cases anyways, as it doesn't support anything
>> not in the e820 at present. Konrad is looking into it.
>>
>> As for the hardware, I've not found any where it would happen. Here's
>> Jan's response where this was discussed previously:
>>
>> -------
>>> For testing purposes, do you have reference for hardware? I don't see
>>> any here with such configuration.
>>
>> Nothing specific, but I know that SR-IOV virtual functions easily
>> cause kernels to run out of MMIO space below 4G (namely when
>> the hole is only around 1Gb or even less), and Intel must have
>> knowledge of graphics cards having so huge a frame buffer that
>> it can only be mapped above 4G.
>>
>> Jan
>> -------
>>
>> IMO, this is a pre-existing condition, that is not specific to
>> PVH only, as such a case would not work for linux PV dom0 either.
> 
> Why are you disabling PVH for all systems then, if it's only a small
> number of systems that may have this problem, and if PV wouldn't work
> on those systems anyway?

The thing is - you can't tell from looking at a system at boot time
whether its kernel would assign MMIO regions above 4Gb. Hence
there's nothing you can qualify a conditional disable on; you
could make a reasonable guess (e.g. summing up all MMIO region
sizes from the PCI device BARs, including not-yet-enabled SR-IOV
ones, and seeing whether that would fit in the MMIO hole below
4Gb), but I think that's not really reasonable.

Otoh the feature is experimental, so I don't see why we shouldn't
allow people to try this out on systems they know the kernel has
no need to assign high MMIO regions.

The fact that "normal" pv-ops has problems with this is irrelevant
here - it's a genuine bug if it can't cope with such a scenario (and
btw. one more of the many reasons making us hesitant to switch
our distros to it).

Jan


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