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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> So, my question is:
> 1) If vBAR = pBAR, does the hypervisor still do any translation?
> I presume it does because it expects the traffic to pass up
> from the root bridge, to the hypervisor and then back, to
> ensure security. If indeed it does do this, where could I
> optionally disable it, and is there an easy to follow bit of
> example code for how to plumb in a boot parameter option for
> this?

It should. 
> 
> 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.

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

   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.

> 
> 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. 
> 
> >>I guess I could test this easily enough by applying the vBAR =
> >>pBAR hack.
> >
> >Does the e820_host=1 option help? That might be PV only though, I
> >can't
> >remember...
> 
> Thanks for pointing this one out, I just found this post in the
> archives:
> http://lists.xen.org/archives/html/xen-users/2012-08/msg00150.html
> 
> With a broken PCIe router, would I also need iommu=soft?

No. The iommu=soft is not needed with the recent pvops linux kernels.
But broken PCIe router's don't have much to do with the kernel - that
is the hypervisor decision whether to allow a guest (either PV or HVM)
to have said device.
> 
> Gordan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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