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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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?

 -George

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