Re: [Xen-devel] HVM support for e820_host (Was: Bug: Limitation of <=2GB RAM in domU persists with 4.3.0)

[Gordan Bobic <gordan@xxxxxxxxxx>]

First attempt at a test run predictably failed. I added e820_host=1 to a 
VM config and tried starting it:
[root@normandy ~]# xl create /etc/xen/edi
Parsing config from /etc/xen/edi
libxl: error: libxl_x86.c:307:libxl__arch_domain_create: Failed while 
collecting E820 with: -3 (errno:-1)
libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot 
(re-)build domain: -3
libxl: error: libxl_dm.c:1300:libxl__destroy_device_model: could not 
find device-model's pid for dom 1
libxl: error: libxl.c:1415:libxl__destroy_domid: 
libxl__destroy_device_model failed for 1
xl-edi.log, qemu-dm-edi.log attached.
Both actually look identical to previous logs before the patch.

Is this something that is clearly a consequence of the patch being 
incomplete? Or did I break something?
Gordan

On 09/03/2013 08:47 PM, Gordan Bobic wrote:
> On 09/03/2013 03:59 PM, Konrad Rzeszutek Wilk wrote:
>
> > > > > 2) Further, I'm finding myself motivated to write that
> > > > > auto-set (as opposed to hard coded) vBAR=pBAR patch discussed
> > > > > briefly a week or so ago (have an init script read the BAR
> > > > > info from dom0 and put it in xenstore, plus a patch to
> > > > > make pBAR=vBAR reservations built dynamically rather than
> > > > > statically, based on this data. Now, I'm quite fluent in C,
> > > > > but my familiarity with Xen soruce code is nearly non-existant
> > > > > (limited to studying an old unsupported patch every now and then
> > > > > in order to make it apply to a more recent code release).
> > > > > Can anyone help me out with a high level view WRT where
> > > > > this would be best plumbed in (which files and the flow of
> > > > > control between the affected files)?
> > > > hvmloader probably and the libxl e820 code. What from a
> > > > high view needs to happen is that:
> > > > 1). Need to relax the check in libxl for e820_hole
> > > >     to also do it for HVM guests. Said code just iterates over the
> > > >     host E820 and sanitizes it a bit and makes a E820 hypercall to
> > > >     set it for the guest.
> [snip]
>
> OK, I have attached a preliminary patch against 4.3.0 for the libxl
> part. It compiles. I haven't tried running it to see if it actually
> works or does something, but my packages build.
>
> Please let me know if I've missed anything. On it's own, I don't think
> this patch will do much (apart from maybe break HVM hosts with
> e820_host=1 set).
>
> > > > 2). Figure out whether the E820 hypercall (which sets the E820
> > > >     layout for a guest) can be run on HVM guests. I think it
> > > >     could not and Mukesh in his PVH patches posted a patch
> > > >     to enable that - "..Move e820 fields out of pv_domain struct"
> Is this already in 4.3.0 or is this an out-of-tree patch? Do you have a
> link to it handy?
>
> > > > 2). Hvmloader should do an E820 get machine memory hypercall
> > > >    to see if there is anything there. If there is - that means
> > > >     the toolstack has request a "new" type of E820. Iterate
> > > >     over the E820 and make it look like that.
> > > >     You can look in the Linux arch/x86/xen/setup.c to see how
> > > >     it does that.
> > > >
> > > >    The complication there is that hvmloader needs to to fit the
> > > >    ACPI code (the guest type one) and such.
> > > >    Presumarily you can just re-use the existing spaces that
> > > >    the host has marked as E820_RESERVED or E820_ACPI..
> > > Yup, I get it. Not only that, but it should also ideally (not
> > > strictly necessary, but it'd be handy) map the IOMEM for devices
> > > it is passed so that pBAR=vBAR (as opposed to just leaving all
> > > the host e820 reserved areas well alone - which would work for
> > > most things).
> > Yes. That is an extra complication that could be done in subsequent
> > patches. But in theory if you have the E820 mirrored from the host the
> > pBAR=vBAR should be easy enough as the values from the host BARs can
> > easily fit in the E820 gaps.
> Agreed. Let's leave the pBAR=vBAR part for a separate patch set. I'll
> have to figure out a sensible way to query the IOMEM regions for each of
> the devices passed to the VM and make sure they are in the same hole.
>
> > > >    Then there is the SMBIOS would need to move and the BIOS
> > > >    might need to be relocated - but I think those are relocatable
> > > >   in some form.
> [bit above left for later reference]
>
> > > > Well, I am more than happy to help you with this.
> > > Thanks, much appreciated. :)
> > Yeeey! Vict^H^H^H^volunteer :-)! <manically laughter in the background>
> >
> > I am also reachable on IRC (FreeNode mostly) as either darnok or konrad
> > if that would be more convient to discuss this.
> Thanks. I'll keep that in mind. :)
>
> Gordan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

Attachment: qemu-dm-edi.log
Description: Text document

Attachment: xl-edi.log
Description: Text document

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