Re: [Xen-devel] Re: [PATCH 0 of 3] Patches for PCI passthrough with modified E820 (v3) - resent.

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

On Fri, May 13, 2011 at 09:57:08AM -0400, Konrad Rzeszutek Wilk wrote:
> > > memhog 4G worked great.. but then I noticed it started slowing down and
> > > it was using the swap disk?
> > 
> > I guess the I/O holes shadowed the RAM and hence it is basically wasted.
> 
> <nods>
> > > Anyhow, seems that if you are using RHEL5, SLES11, you need to be 
> > > carefull to
> > > use 'memory' and 'maxmem'.
> > 
> > Hrm, changing behaviour for existing guests isn't so nice, at least not
> > without a way to turn the behaviour off, perhaps we do need an explicit
> > cfg file variable to control this after all?
> 
> We could do that, and then once your idea below has been completly working
> we can rip out the parameter?

How does this patch look to your eyes:

# HG changeset patch
# Parent c6fa04014d6e99ca4e62d04132180338403c0478
libxl: Add 'e820_host' option to config file.

.. which will be removed once the auto-ballooning of guests
with PCI devices works. During testing of the patches which provide
a host E820 in a PV guest, certain inconsistencies were found with
guests. When launching a RHEL5 or SLES11 PV guest with 4GB and a PCI device,
the kernel would report 4GB, but have 1.5G "used". What happend was that
the P2M that fall within the E820 I/O holes would never be used and was just
wasted. The mechanism to go around this is to shrink the size of the guest
before launch (say memory=2048, maxmem=4096) and then balloon back to 4096M
after start. For PVOPS type kernels it would detect the E820 I/O holes and
deflate by the correct amount but would not inflate back to 4GB.
Manually inflating makes it work.

The fix in the future for guests where the memory amount flows over the
PCI hole, is to launch the guest with decreased amount right up to the cusp
of where the E820 PCI hole starts. Also increase the 'maxmem' by the delta
and then when the guest has launched, balloon up to the delta number.

This will require some careful surgery so for right now this parameter
will guard against unsuspecting users seeing their PV guests memory "vanish."

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

diff -r c6fa04014d6e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Tue May 17 10:33:27 2011 -0400
+++ b/tools/libxl/xl_cmdimpl.c  Tue May 17 11:03:44 2011 -0400
@@ -626,6 +626,7 @@ static void parse_config_data(const char
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 1;
+    int e820_host_override = 0;
     int e;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -979,6 +980,10 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
         pci_power_mgmt = l;
 
+    /* To be removed once the auto ballooning after guest starts is done. */
+    if (!xlu_cfg_get_long (config, "e820_host", &l))
+        e820_host_override = l;
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -995,7 +1000,7 @@ skip_vfb:
             if (!libxl_device_pci_parse_bdf(ctx, pcidev, buf))
                 d_config->num_pcidevs++;
         }
-        if (d_config->num_pcidevs && !c_info->hvm)
+        if (d_config->num_pcidevs && !c_info->hvm && e820_host_override)
           b_info->u.pv.machine_e820 = true;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel