[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Bug: Limitation of <=2GB RAM in domU persists with 4.3.0



On Mon, 29 Jul 2013 14:04:31 -0400, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

Hi Konrad,

Apologies it took me a month to get back to this.

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.

I'm looking at the libxl code at the moment.

In cases where e820_host is seen as PV specific, would the
correct thing to do be to move it out of the PV/HVM specific
blocks so it applies to both?

In libxl/libxl_x86.c/libxl__e820_alloc

I have thus far changed the code to remove the PV check,
and having moved e820_host option to be common to both VM
types, I changed the 820 related instances from
b_info->u.pv.e820_host
to
b_info->e820_host

Is this the correct/preferred way this should be handled?
Or would it be better to make e820_host be in both PV and
HVM options, and refer to it as such
(u.pv.e820_host / u.hvm.e820_host) ?

The e820 sanitizer is called with b_info->u.pv.slack_memkb
parameter. What does parameter actually mean? I googled
it and couldn't find any documentation specific to it, and
it doesn't appear to be documented as settable in the config
file. What would the equivalent be in case of HVM?

 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"
 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).

   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.

OK, I'll look at that once I have a workable patch for the libxl
part.

The added bonus of this (if it can be made to work) is that
it might just make unmodified GeForce cards work, too,
which probably makes it worthwhile on it's own.

Well, I am more than happy to help you with this.

Thanks, much appreciated. :)

Gordan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.