David Stone
2008-Jan-18 21:02 UTC
[Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
Keir,
Here''s a first patch to address the issue with rolling over to
guest-physical address 0x00000000 when assigning address regions to
PCI BARs during HVM boot. For now, this:
- Makes the hole bigger: 0xC0000000-0xF5000000. This might be
overkill...but it should only matter for 32-bit guest OSes assigned
more than 3GB of RAM.
- Prevents addresses from above 0xF50000000 from being assigned to
PCI devices by the HVM BIOS (and prevents rollover to 0x00000000)
I also have some code to parse the DSDT''s ASL code to more dynamically
assign the memory hole for PCI BARs. Do you think it''s worth worrying
about this, since again it should only come in handy if you have more
than 3GB of RAM aassigned to a 32-bit guest OS? I tried the approach
of having two different chunks of ASL code (in different SSDTs or
whatever) but couldn''t get that to work, so now I have code to modify
the ASL code directly.
Also, this is my first attempt at submitting code to Xen so please let
me know of any faux-pas I might be committing.
Thanks,
Dave
# HG changeset patch
# User root@localhost.localdomain
# Date 1200689221 18000
# Node ID dba8f029e22298b4d5777499d14524de58fc89f0
# Parent 62fc84adc8ed30477759461fe5ade47f19b084f4
Make the memory hole in guest-physical memory for use by guest''s PCI
BARs bigger.
Also prevent roll-over if the PCI BARs don''t fit into the hole.
Signed-off-by: David Stone david.stone@citrix.com
diff -r 62fc84adc8ed -r dba8f029e222 tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl Fri Jan 18 13:43:26 2008 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl Fri Jan 18 15:47:01 2008 -0500
@@ -115,15 +115,21 @@ DefinitionBlock ("DSDT.aml", "DSDT",
2,
0x000BFFFF,
0x00000000,
0x00020000)
-
+
+ /* This hole for pci devices is made pretty big here, in
+ * case there is a device that needs a lot of address space
+ * (like a modern graphics card). This is only a potential
+ * issue on a 32-bit guest if you are assigning it more than
+ * ~3G of RAM
+ */
DWordMemory(
ResourceConsumer, PosDecode, MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x00000000,
- 0xF0000000,
+ 0xC0000000,
0xF4FFFFFF,
0x00000000,
- 0x05000000)
+ 0x35000000)
})
Return (PRT0)
}
diff -r 62fc84adc8ed -r dba8f029e222 tools/firmware/hvmloader/acpi/dsdt.c
--- a/tools/firmware/hvmloader/acpi/dsdt.c Fri Jan 18 13:43:26 2008 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.c Fri Jan 18 15:47:01 2008 -0500
@@ -1,11 +1,11 @@
/*
*
* Intel ACPI Component Architecture
- * ASL Optimizing Compiler version 20060707 [Feb 16 2007]
+ * ASL Optimizing Compiler version 20060707 [Jan 18 2008]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
- * Compilation of "dsdt.asl" - Tue Sep 11 16:12:28 2007
+ * Compilation of "dsdt.asl" - Fri Jan 18 15:31:56 2008
*
* C source code output
*
@@ -60,8 +60,8 @@ unsigned char AmlCode[]
0xFF,0xFF,0x0B,0x00,0x00,0x00,0x00,0x00, /* 00000168 "........" */
0x00,0x00,0x02,0x00,0x87,0x17,0x00,0x00, /* 00000170
"........" */
0x0D,0x03,0x00,0x00,0x00,0x00,0x00,0x00, /* 00000178
"........" */
- 0x00,0xF0,0xFF,0xFF,0xFF,0xF4,0x00,0x00, /* 00000180
"........" */
- 0x00,0x00,0x00,0x00,0x00,0x05,0x79,0x00, /* 00000188
"......y." */
+ 0x00,0xC0,0xFF,0xFF,0xFF,0xF4,0x00,0x00, /* 00000180
"........" */
+ 0x00,0x00,0x00,0x00,0x00,0x35,0x79,0x00, /* 00000188
".....5y." */
0xA4,0x50,0x52,0x54,0x30,0x08,0x42,0x55, /* 00000190
".PRT0.BU" */
0x46,0x41,0x11,0x09,0x0A,0x06,0x23,0x20, /* 00000198 "FA....#
" */
0x0C,0x18,0x79,0x00,0x08,0x42,0x55,0x46, /* 000001A0
"..y..BUF" */
diff -r 62fc84adc8ed -r dba8f029e222 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Fri Jan 18 13:43:26 2008 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c Fri Jan 18 15:47:01 2008 -0500
@@ -183,7 +183,7 @@ static void apic_setup(void)
static void pci_setup(void)
{
- uint32_t devfn, bar_reg, bar_data, bar_sz, cmd;
+ uint32_t devfn, bar_reg, bar_data, bar_sz, cmd, mem_base_test;
uint32_t *base, io_base = 0xc000, mem_base = HVM_BELOW_4G_MMIO_START;
uint16_t class, vendor_id, device_id;
unsigned int bar, pin, link, isa_irq;
@@ -254,16 +254,34 @@ static void pci_setup(void)
base = &mem_base;
bar_sz &= PCI_BASE_ADDRESS_MEM_MASK;
bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+ bar_sz &= ~(bar_sz - 1);
+ mem_base_test = (*base + bar_sz - 1) & ~(bar_sz - 1);
+ if ( (mem_base_test < HVM_BELOW_4G_MMIO_START) ||
+ ( (mem_base_test+bar_sz) < HVM_BELOW_4G_MMIO_START)
||
+ ( (mem_base_test+bar_sz) > HVM_BELOW_4G_MMIO_END))
+ {
+ /*
+ * The PCI device''s BAR won''t fit
into the
hole (it might
+ * even have wrapped around). So, don''t
enable this BAR!
+ */
+ cmd = pci_readw(devfn, PCI_COMMAND);
+ cmd &= ~PCI_COMMAND_MEMORY;
+ pci_writew(devfn, PCI_COMMAND, cmd);
+ printf("pci dev %02x:%x bar %02x (size: %08x)
is too big!\n",
+ devfn>>3, devfn&7, bar_reg, bar_sz);
+ break;
+ }
+ *base = mem_base_test;
}
else
{
base = &io_base;
bar_sz &= PCI_BASE_ADDRESS_IO_MASK & 0xffff;
bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
+ bar_sz &= ~(bar_sz - 1);
+ *base = (*base + bar_sz - 1) & ~(bar_sz - 1);
}
- bar_sz &= ~(bar_sz - 1);
-
- *base = (*base + bar_sz - 1) & ~(bar_sz - 1);
+
bar_data |= *base;
*base += bar_sz;
diff -r 62fc84adc8ed -r dba8f029e222 xen/include/public/hvm/e820.h
--- a/xen/include/public/hvm/e820.h Fri Jan 18 13:43:26 2008 +0000
+++ b/xen/include/public/hvm/e820.h Fri Jan 18 15:47:01 2008 -0500
@@ -27,8 +27,14 @@
#define HVM_E820_NR_OFFSET 0x000001E8
#define HVM_E820_OFFSET 0x000002D0
-#define HVM_BELOW_4G_RAM_END 0xF0000000
+/*
+ * These limits define where in guest-physical address space the
guest''s PCI
+ * devices get their BARs mapped to. They should match the values given
+ * by the guest ACPI (in dsdt.asl).
+ */
+#define HVM_BELOW_4G_RAM_END 0xC0000000
#define HVM_BELOW_4G_MMIO_START HVM_BELOW_4G_RAM_END
-#define HVM_BELOW_4G_MMIO_LENGTH ((1ULL << 32) -
HVM_BELOW_4G_MMIO_START)
+#define HVM_BELOW_4G_MMIO_END 0xF5000000
+#define HVM_BELOW_4G_MMIO_LENGTH (HVM_BELOW_4G_MMIO_END -
HVM_BELOW_4G_MMIO_START)
#endif /* __XEN_PUBLIC_HVM_E820_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jan-18 21:31 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
That''s a very big hole. We should do this more dynamically. -- Keir On 18/1/08 21:02, "David Stone" <unclestoner@gmail.com> wrote:> Keir, > Here''s a first patch to address the issue with rolling over to > guest-physical address 0x00000000 when assigning address regions to > PCI BARs during HVM boot. For now, this: > - Makes the hole bigger: 0xC0000000-0xF5000000. This might be > overkill...but it should only matter for 32-bit guest OSes assigned > more than 3GB of RAM. > - Prevents addresses from above 0xF50000000 from being assigned to > PCI devices by the HVM BIOS (and prevents rollover to 0x00000000) > > I also have some code to parse the DSDT''s ASL code to more dynamically > assign the memory hole for PCI BARs. Do you think it''s worth worrying > about this, since again it should only come in handy if you have more > than 3GB of RAM aassigned to a 32-bit guest OS? I tried the approach > of having two different chunks of ASL code (in different SSDTs or > whatever) but couldn''t get that to work, so now I have code to modify > the ASL code directly. > > Also, this is my first attempt at submitting code to Xen so please let > me know of any faux-pas I might be committing. > > Thanks, > Dave > > # HG changeset patch > # User root@localhost.localdomain > # Date 1200689221 18000 > # Node ID dba8f029e22298b4d5777499d14524de58fc89f0 > # Parent 62fc84adc8ed30477759461fe5ade47f19b084f4 > Make the memory hole in guest-physical memory for use by guest''s PCI > BARs bigger. > Also prevent roll-over if the PCI BARs don''t fit into the hole. > Signed-off-by: David Stone david.stone@citrix.com > > diff -r 62fc84adc8ed -r dba8f029e222 tools/firmware/hvmloader/acpi/dsdt.asl > --- a/tools/firmware/hvmloader/acpi/dsdt.asl Fri Jan 18 13:43:26 2008 +0000 > +++ b/tools/firmware/hvmloader/acpi/dsdt.asl Fri Jan 18 15:47:01 2008 -0500 > @@ -115,15 +115,21 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, > 0x000BFFFF, > 0x00000000, > 0x00020000) > - > + > + /* This hole for pci devices is made pretty big here, in > + * case there is a device that needs a lot of address space > + * (like a modern graphics card). This is only a potential > + * issue on a 32-bit guest if you are assigning it more than > + * ~3G of RAM > + */ > DWordMemory( > ResourceConsumer, PosDecode, MinFixed, MaxFixed, > Cacheable, ReadWrite, > 0x00000000, > - 0xF0000000, > + 0xC0000000, > 0xF4FFFFFF, > 0x00000000, > - 0x05000000) > + 0x35000000) > }) > Return (PRT0) > } > diff -r 62fc84adc8ed -r dba8f029e222 tools/firmware/hvmloader/acpi/dsdt.c > --- a/tools/firmware/hvmloader/acpi/dsdt.c Fri Jan 18 13:43:26 2008 +0000 > +++ b/tools/firmware/hvmloader/acpi/dsdt.c Fri Jan 18 15:47:01 2008 -0500 > @@ -1,11 +1,11 @@ > /* > * > * Intel ACPI Component Architecture > - * ASL Optimizing Compiler version 20060707 [Feb 16 2007] > + * ASL Optimizing Compiler version 20060707 [Jan 18 2008] > * Copyright (C) 2000 - 2006 Intel Corporation > * Supports ACPI Specification Revision 3.0a > * > - * Compilation of "dsdt.asl" - Tue Sep 11 16:12:28 2007 > + * Compilation of "dsdt.asl" - Fri Jan 18 15:31:56 2008 > * > * C source code output > * > @@ -60,8 +60,8 @@ unsigned char AmlCode[] > 0xFF,0xFF,0x0B,0x00,0x00,0x00,0x00,0x00, /* 00000168 "........" */ > 0x00,0x00,0x02,0x00,0x87,0x17,0x00,0x00, /* 00000170 "........" */ > 0x0D,0x03,0x00,0x00,0x00,0x00,0x00,0x00, /* 00000178 "........" */ > - 0x00,0xF0,0xFF,0xFF,0xFF,0xF4,0x00,0x00, /* 00000180 "........" */ > - 0x00,0x00,0x00,0x00,0x00,0x05,0x79,0x00, /* 00000188 "......y." */ > + 0x00,0xC0,0xFF,0xFF,0xFF,0xF4,0x00,0x00, /* 00000180 "........" */ > + 0x00,0x00,0x00,0x00,0x00,0x35,0x79,0x00, /* 00000188 ".....5y." */ > 0xA4,0x50,0x52,0x54,0x30,0x08,0x42,0x55, /* 00000190 ".PRT0.BU" */ > 0x46,0x41,0x11,0x09,0x0A,0x06,0x23,0x20, /* 00000198 "FA....# " */ > 0x0C,0x18,0x79,0x00,0x08,0x42,0x55,0x46, /* 000001A0 "..y..BUF" */ > diff -r 62fc84adc8ed -r dba8f029e222 tools/firmware/hvmloader/hvmloader.c > --- a/tools/firmware/hvmloader/hvmloader.c Fri Jan 18 13:43:26 2008 +0000 > +++ b/tools/firmware/hvmloader/hvmloader.c Fri Jan 18 15:47:01 2008 -0500 > @@ -183,7 +183,7 @@ static void apic_setup(void) > > static void pci_setup(void) > { > - uint32_t devfn, bar_reg, bar_data, bar_sz, cmd; > + uint32_t devfn, bar_reg, bar_data, bar_sz, cmd, mem_base_test; > uint32_t *base, io_base = 0xc000, mem_base = HVM_BELOW_4G_MMIO_START; > uint16_t class, vendor_id, device_id; > unsigned int bar, pin, link, isa_irq; > @@ -254,16 +254,34 @@ static void pci_setup(void) > base = &mem_base; > bar_sz &= PCI_BASE_ADDRESS_MEM_MASK; > bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK; > + bar_sz &= ~(bar_sz - 1); > + mem_base_test = (*base + bar_sz - 1) & ~(bar_sz - 1); > + if ( (mem_base_test < HVM_BELOW_4G_MMIO_START) || > + ( (mem_base_test+bar_sz) < HVM_BELOW_4G_MMIO_START) > || > + ( (mem_base_test+bar_sz) > HVM_BELOW_4G_MMIO_END)) > + { > + /* > + * The PCI device''s BAR won''t fit into the > hole (it might > + * even have wrapped around). So, don''t > enable this BAR! > + */ > + cmd = pci_readw(devfn, PCI_COMMAND); > + cmd &= ~PCI_COMMAND_MEMORY; > + pci_writew(devfn, PCI_COMMAND, cmd); > + printf("pci dev %02x:%x bar %02x (size: %08x) > is too big!\n", > + devfn>>3, devfn&7, bar_reg, bar_sz); > + break; > + } > + *base = mem_base_test; > } > else > { > base = &io_base; > bar_sz &= PCI_BASE_ADDRESS_IO_MASK & 0xffff; > bar_data &= ~PCI_BASE_ADDRESS_IO_MASK; > + bar_sz &= ~(bar_sz - 1); > + *base = (*base + bar_sz - 1) & ~(bar_sz - 1); > } > - bar_sz &= ~(bar_sz - 1); > - > - *base = (*base + bar_sz - 1) & ~(bar_sz - 1); > + > bar_data |= *base; > *base += bar_sz; > > diff -r 62fc84adc8ed -r dba8f029e222 xen/include/public/hvm/e820.h > --- a/xen/include/public/hvm/e820.h Fri Jan 18 13:43:26 2008 +0000 > +++ b/xen/include/public/hvm/e820.h Fri Jan 18 15:47:01 2008 -0500 > @@ -27,8 +27,14 @@ > #define HVM_E820_NR_OFFSET 0x000001E8 > #define HVM_E820_OFFSET 0x000002D0 > > -#define HVM_BELOW_4G_RAM_END 0xF0000000 > +/* > + * These limits define where in guest-physical address space the guest''s PCI > + * devices get their BARs mapped to. They should match the values given > + * by the guest ACPI (in dsdt.asl). > + */ > +#define HVM_BELOW_4G_RAM_END 0xC0000000 > #define HVM_BELOW_4G_MMIO_START HVM_BELOW_4G_RAM_END > -#define HVM_BELOW_4G_MMIO_LENGTH ((1ULL << 32) - HVM_BELOW_4G_MMIO_START) > +#define HVM_BELOW_4G_MMIO_END 0xF5000000 > +#define HVM_BELOW_4G_MMIO_LENGTH (HVM_BELOW_4G_MMIO_END - > HVM_BELOW_4G_MMIO_START) > > #endif /* __XEN_PUBLIC_HVM_E820_H__ */ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Stone
2008-Jan-21 13:41 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
On Jan 18, 2008 4:31 PM, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> That''s a very big hole. We should do this more dynamically.OK fair enough. As I said I have some code that dynamically modifies the DSDT''s AML. I''ll try to finish it up and submit it. But in the meantime, will you take a patch (a subset of the patch I just submitted) that keeps the hole as it is (starting at 0xF0000000) but ensures it doesn''t roll over to 0x00000000 in the Xen HVM BIOS? Also should the hole used by the Xen HVM BIOS be limited to 0xF0000000-0xF4FFFFFF rather than 0xF00000000-0xFFFFFFFF? Because: - The current DSDT specifies 0xF0000000-0xF4FFFFFF. - My understanding is that various other systems/components use certain addresses at the top of 32-bit physical address space (like maybe MSIs?). So it would be bad to assign those physical addresses to random PCI devices. My only hesitation is that 0xF0000000-0xF4FFFFFF = 80Mb is smallish, especially considering the wasteful algorithm the Xen HVM BIOS currently uses to assign addresses (it can waste a lot of space). Thanks, Dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jan-21 14:59 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
On 21/1/08 13:41, "David Stone" <unclestoner@gmail.com> wrote:> OK fair enough. As I said I have some code that dynamically modifies > the DSDT''s AML. I''ll try to finish it up and submit it.Actually that''s a bad way to do it. I''ve just checked in a patch which modifies the DSDT to fetch the PCI hole parameters from a memory location which is initialised by hvmloader.> But in the meantime, will you take a patch (a subset of the patch I > just submitted) that keeps the hole as it is (starting at 0xF0000000) > but ensures it doesn''t roll over to 0x00000000 in the Xen HVM BIOS?Yes.> Also should the hole used by the Xen HVM BIOS be limited to > 0xF0000000-0xF4FFFFFF rather than 0xF00000000-0xFFFFFFFF? Because: > - The current DSDT specifies 0xF0000000-0xF4FFFFFF.I think this is because it was "big enough" for the Intel engineer who first did the Xen ACPI work. There''s no reason not to go up to, say, FC000000. We can''t go all the way to 4GB because there a couple of things up there (at least LAPIC and IOAPIC mappings).> - My understanding is that various other systems/components use > certain addresses at the top of 32-bit physical address space (like > maybe MSIs?). So it would be bad to assign those physical addresses > to random PCI devices.If we leave 64MB it should be plenty.> My only hesitation is that 0xF0000000-0xF4FFFFFF = 80Mb is smallish, > especially considering the wasteful algorithm the Xen HVM BIOS > currently uses to assign addresses (it can waste a lot of space).How is it wasteful? We could only do better if we assigned PCI resources in descending order of size (and hence alignment requirement). Which we *could* do, I suppose. Certainly the resource assignment code is going to get rather more exciting anyway, to fully support the dynamic PCI hole. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jan-21 15:07 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
On 21/1/08 14:59, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:>> Also should the hole used by the Xen HVM BIOS be limited to >> 0xF0000000-0xF4FFFFFF rather than 0xF00000000-0xFFFFFFFF? Because: >> - The current DSDT specifies 0xF0000000-0xF4FFFFFF. > > I think this is because it was "big enough" for the Intel engineer who first > did the Xen ACPI work. There''s no reason not to go up to, say, FC000000. We > can''t go all the way to 4GB because there a couple of things up there (at > least LAPIC and IOAPIC mappings).Actually, if we do this, will 192MB be enough to be getting along with anyway, for any devices anyone is currently testing with pass-thru? Adding the roll-over check is obviously a good idea anyway. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Stone
2008-Jan-21 19:28 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
> > My only hesitation is that 0xF0000000-0xF4FFFFFF = 80Mb is smallish, > > especially considering the wasteful algorithm the Xen HVM BIOS > > currently uses to assign addresses (it can waste a lot of space). > > How is it wasteful? We could only do better if we assigned PCI resources in > descending order of size (and hence alignment requirement). Which we *could* > do, I suppose. Certainly the resource assignment code is going to get rather > more exciting anyway, to fully support the dynamic PCI hole.Pretty much that...the way it is now if the order in which BARs are enumerated is such that the first BAR wants a small amount (say 1KB and gets 0xF0000000-0xF00003FF) and then the second BAR wants a large amout (say 64 MB and gets 0xF4000000-0xF7FFFFFF) then a there is a big waste (0xF0000400-0xF3FFFFFF == ~64 MB). In the various configurations I was running almost as much PCI device address space got wasted as assigned. Thanks, Dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dan Doucette
2008-Feb-29 20:55 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
Hello David,Keir,
I am trying to increase the PCI aperture in my vista guest using the direct
approach outlined by David above, i.e. modifying dsdt.asl and recompiling.
This does not work, and I am wondering about the statement made above by
Keir,
" Actually that''s a bad way to do it. I''ve just checked
in a patch which
modifies the DSDT to fetch the PCI hole parameters from a memory location
which is initialised by hvmloader. "
Is this update the code in hvmloader.c:pci_setup.c
struct resource mem_resource = { 0xf0000000, 0xfc000000 };
...
By modifying that constant to 0xc0000000, I do see devices enumerated in
vista starting at 0xc0000000, but the acpi pci bus device in vista still
reports an aperture starting at 0xf0000000, which I believe is fetched from
dsdt tables.?
Thanks,
Dan.
On Mon, Jan 21, 2008 at 11:28 AM, David Stone <unclestoner@gmail.com>
wrote:
> > > My only hesitation is that 0xF0000000-0xF4FFFFFF = 80Mb is
smallish,
> > > especially considering the wasteful algorithm the Xen HVM BIOS
> > > currently uses to assign addresses (it can waste a lot of space).
> >
> > How is it wasteful? We could only do better if we assigned PCI
resources
> in
> > descending order of size (and hence alignment requirement). Which we
> *could*
> > do, I suppose. Certainly the resource assignment code is going to get
> rather
> > more exciting anyway, to fully support the dynamic PCI hole.
>
> Pretty much that...the way it is now if the order in which BARs are
> enumerated is such that the first BAR wants a small amount (say 1KB
> and gets 0xF0000000-0xF00003FF) and then the second BAR wants a large
> amout (say 64 MB and gets 0xF4000000-0xF7FFFFFF) then a there is a big
> waste (0xF0000400-0xF3FFFFFF == ~64 MB). In the various
> configurations I was running almost as much PCI device address space
> got wasted as assigned.
>
> Thanks,
> Dave
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2008-Mar-01 08:50 UTC
Re: [Xen-devel] [Patch] Make memory hole for PCI Express bigger and prevent roll-over
You missed hvmloader/acpi/build.c:construct_bios_info_table(). Apologies for the lack of referential integrity. -- Keir On 29/2/08 20:55, "Dan Doucette" <doucette.daniel@gmail.com> wrote:> Hello David,Keir, > > I am trying to increase the PCI aperture in my vista guest using the direct > approach outlined by David above, i.e. modifying dsdt.asl and recompiling. > > This does not work, and I am wondering about the statement made above by Keir, > > " Actually that''s a bad way to do it. I''ve just checked in a patch which > modifies the DSDT to fetch the PCI hole parameters from a memory location > which is initialised by hvmloader. " > > Is this update the code in hvmloader.c:pci_setup.c > > struct resource mem_resource = { 0xf0000000, 0xfc000000 }; > ... > > By modifying that constant to 0xc0000000, I do see devices enumerated in vista > starting at 0xc0000000, but the acpi pci bus device in vista still reports an > aperture starting at 0xf0000000, which I believe is fetched from dsdt tables.? > > Thanks, > > Dan. > > > > On Mon, Jan 21, 2008 at 11:28 AM, David Stone <unclestoner@gmail.com> wrote: >>>> > > My only hesitation is that 0xF0000000-0xF4FFFFFF = 80Mb is smallish, >>>> > > especially considering the wasteful algorithm the Xen HVM BIOS >>>> > > currently uses to assign addresses (it can waste a lot of space). >>> > >>> > How is it wasteful? We could only do better if we assigned PCI resources >>> in >>> > descending order of size (and hence alignment requirement). Which we >>> *could* >>> > do, I suppose. Certainly the resource assignment code is going to get >>> rather >>> > more exciting anyway, to fully support the dynamic PCI hole. >> >> Pretty much that...the way it is now if the order in which BARs are >> enumerated is such that the first BAR wants a small amount (say 1KB >> and gets 0xF0000000-0xF00003FF) and then the second BAR wants a large >> amout (say 64 MB and gets 0xF4000000-0xF7FFFFFF) then a there is a big >> waste (0xF0000400-0xF3FFFFFF == ~64 MB). In the various >> configurations I was running almost as much PCI device address space >> got wasted as assigned. >> >> Thanks, >> Dave >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel