Re: [SeaBIOS] [Qemu-devel] [seabios patch 0/5] dynamic pci i/o windows
On Mon, May 07, 2012 at 01:58:18PM +1200, Alexey Korolev wrote: > Hi, > Tried these patches today on Win2008 x64 guest with 64bit devices. > I've got BSOD on boot. I guess windows don't like changes in _CRS. Hrmm, I went to test this, and found that the "Fix 64bit PCI issues on Windows" patch causes winxp to BSOD. So, it looks like that patch will have to be reverted. We'll need to dynamically generate the _CRS somehow. The DSDT is a real pain. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [seabios patch 0/5] dynamic pci i/o windows
Hi, Tried these patches today on Win2008 x64 guest with 64bit devices. I've got BSOD on boot. I guess windows don't like changes in _CRS. On 04/05/12 20:21, Gerd Hoffmann wrote: > Hi, > > This patch series makes the PCI I/O windows runtime-configurable via > qemu firmware config interface. Main advantage is that we can size and > shuffle around the PCI i/O windows according to the amount of memory the > virtual machine has. We don't need a hole for 64bit PCI bars, we can > just map them above the main memory. The hole for 32bit PCI bars can be > enlarged for guests with less than 3.5 GB of memory. > > Oh, and the pci device initialization fix is there too ;) > > cheers, > Gerd > > Gerd Hoffmann (5): > pci: init all devices > acpi: add qemu fwcfg driver > acpi: update pci io windows according to fw_cfg info > pciinit: make pci ressources configurable > update src/acpi-dsdt.hex > > src/acpi-dsdt.dsl | 81 ++- > src/acpi-dsdt.hex | 420 > +++-- > src/paravirt.c|8 + > src/paravirt.h|2 + > src/pciinit.c | 32 +++- > 5 files changed, 522 insertions(+), 21 deletions(-) > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios <>___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
Fred . wrote: > And in terms of standards compliance? The nature of BIOS is that there isn't a standard to comply with. > I know proprietary BIOS have advantage when it comes to SMBIOS due > to the implementation in SeaBIOS lagging behind several versions. Do you know of concrete issues because of this lag, or did you notice a number that is smaller in SeaBIOS than somewhere else? Ie. do you see a technical disadvantage because of the difference in SMBIOS versions? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
And in terms of standards compliance? I know proprietary BIOS have advantage when it comes to SMBIOS due to the implementation in SeaBIOS lagging behind several versions. On Sun, May 6, 2012 at 8:00 PM, Peter Stuge wrote: > Fred . wrote: >> How is SeaBIOS working towards the non-technical goals of the project? > > This is not so clear. I'm not even sure that there are non-technical > goals for the project. > > Competing with commercial BIOS products would require a company to > put a SeaBIOS-based PC firmware to market, quite likely in concert > with coreboot. I know of one company which offers among other things > coreboot services, Sage Engineering, who are quite active in the > coreboot community. http://www.se-eng.com/coreboot.html > > But even so you can see that the business model is different from > commercial BIOS products, and already this small difference presents > a non-technical challenge. SeaBIOS lacks documentation. It lacks communication. The website is not updated with news about the development. There is no mention of what's new, whats planned, etc. > > >> That said, still curious about a technical comparison. > > As far as BIOS goes, SeaBIOS will boot and run I believe any OS that > a commercial BIOS product does. Differences at this point are perhaps > primarily how the build is configured and run, how execution is > configured, and the presentation of SeaBIOS during runtime. > > Because SeaBIOS has a technical goal of not spending more time than > neccessary on any task, there isn't much presentation to talk about. > > Build configuration in SeaBIOS is based on Kconfig, comfortable for > anyone who has built a Linux kernel or busybox, but perhaps not > completely intuitive for developers who primarily have experience > from using Windows systems. > > The build system itself of SeaBIOS relies on the GNU toolchain, > including optionally rather new features, contrary to commercial > BIOS products which typically rely on quite old Microsoft toolchains. > > Runtime configuration in SeaBIOS consists of the F12 menu when > multiple boot sources are found, and the QEMU-specific fwcfg > interface - compared to the classic text-mode setup menu screens in > commercial BIOS products. > > Then there's of course the fact that BIOS is no longer really > relevant for many mainboard vendors, whose customers expect UEFI. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
Fred . wrote: > How is SeaBIOS working towards the non-technical goals of the project? This is not so clear. I'm not even sure that there are non-technical goals for the project. Competing with commercial BIOS products would require a company to put a SeaBIOS-based PC firmware to market, quite likely in concert with coreboot. I know of one company which offers among other things coreboot services, Sage Engineering, who are quite active in the coreboot community. http://www.se-eng.com/coreboot.html But even so you can see that the business model is different from commercial BIOS products, and already this small difference presents a non-technical challenge. > That said, still curious about a technical comparison. As far as BIOS goes, SeaBIOS will boot and run I believe any OS that a commercial BIOS product does. Differences at this point are perhaps primarily how the build is configured and run, how execution is configured, and the presentation of SeaBIOS during runtime. Because SeaBIOS has a technical goal of not spending more time than neccessary on any task, there isn't much presentation to talk about. Build configuration in SeaBIOS is based on Kconfig, comfortable for anyone who has built a Linux kernel or busybox, but perhaps not completely intuitive for developers who primarily have experience from using Windows systems. The build system itself of SeaBIOS relies on the GNU toolchain, including optionally rather new features, contrary to commercial BIOS products which typically rely on quite old Microsoft toolchains. Runtime configuration in SeaBIOS consists of the F12 menu when multiple boot sources are found, and the QEMU-specific fwcfg interface - compared to the classic text-mode setup menu screens in commercial BIOS products. Then there's of course the fact that BIOS is no longer really relevant for many mainboard vendors, whose customers expect UEFI. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
How is SeaBIOS working towards the non-technical goals of the project? That said, still curious about a technical comparison. On Sun, May 6, 2012 at 4:36 PM, Peter Stuge wrote: > This has very little to do with technical properties, and is much > more about politics which obviously require a different approach > than technicalities. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
This has very little to do with technical properties, and is much more about politics which obviously require a different approach than technicalities. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] SeaBIOS vs other BIOS?
What features and functionality does SeaBIOS have that other BIOS does not? What features and functionality does other BIOS have that is better than what SeaBIOS offers? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [seabios patch 0/5] dynamic pci i/o windows
On Fri, May 04, 2012 at 11:37:25AM -0400, Kevin O'Connor wrote:
> On Fri, May 04, 2012 at 10:46:00AM -0400, Kevin O'Connor wrote:
> > On Fri, May 04, 2012 at 04:01:56PM +0200, Gerd Hoffmann wrote:
> > > On 05/04/12 15:18, Kevin O'Connor wrote:
> > > > On Fri, May 04, 2012 at 10:21:22AM +0200, Gerd Hoffmann wrote:
> > > >> Hi,
> > > >>
> > > >> This patch series makes the PCI I/O windows runtime-configurable via
> > > >> qemu firmware config interface. Main advantage is that we can size and
> > > >> shuffle around the PCI i/O windows according to the amount of memory
> > > >> the
> > > >> virtual machine has. We don't need a hole for 64bit PCI bars, we can
> > > >> just map them above the main memory. The hole for 32bit PCI bars can
> > > >> be
> > > >> enlarged for guests with less than 3.5 GB of memory.
> > > >
> > > > Why pass in a PCI IO range through fw_cfg if SeaBIOS can figure out an
> > > > acceptable range from the amount of memory in the machine?
> > >
> > > Suggestions on how to update the pci host bridge windows in the dsdt then?
> >
> > Perhaps malloc_high() a struct with the info you need and then create
> > an OperationRegion() in the dynamically generated SSDT with the
> > address of the struct.
>
> I played with this a little and came up with the below as an example.
>
IMO that is much better than reading fw_cfg from AML. fw_cfg wasn't
meant to be touched while OS is running. Another option is to patch the
DSDT directly. We have the infrastructure for that in place.
> -Kevin
>
>
> diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
> index 4a18617..960f9fb 100644
> --- a/src/acpi-dsdt.dsl
> +++ b/src/acpi-dsdt.dsl
> @@ -132,7 +132,7 @@ DefinitionBlock (
> B0EJ, 32,
> }
>
> -Name (_CRS, ResourceTemplate ()
> +Name (CRES, ResourceTemplate ()
> {
> WordBusNumber (ResourceProducer, MinFixed, MaxFixed,
> PosDecode,
> 0x, // Address Space Granularity
> @@ -183,6 +183,18 @@ DefinitionBlock (
> 0x80,// Address Length
> ,, , AddressRangeMemory, TypeStatic)
> })
> +Method (_CRS, 0)
> +{
> +External (\_SB.BDAT)
> +Field(\_SB.BDAT, DWordAcc, NoLock, Preserve) {
> +VAL1, 32,
> +VAL2, 32,
> +}
> +DBUG("Got")
> +DBUG(VAL1)
> +DBUG(VAL2)
> +Return (CRES)
> +}
> }
> }
>
> diff --git a/src/acpi.c b/src/acpi.c
> index 30888b9..3e0d4da 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -415,7 +415,8 @@ build_ssdt(void)
> int length = ((1+3+4)
>+ (acpi_cpus * SD_SIZEOF)
>+ (1+2+5+(12*acpi_cpus))
> - + (6+2+1+(1*acpi_cpus)));
> + + (6+2+1+(1*acpi_cpus))
> + + 17);
> u8 *ssdt = malloc_high(sizeof(struct acpi_table_header) + length);
> if (! ssdt) {
> warn_noalloc();
> @@ -477,6 +478,26 @@ build_ssdt(void)
> for (i=0; i *(ssdt_ptr++) = (i < CountCPUs) ? 0x01 : 0x00;
>
> +// XXX
> +u32 *myval = malloc_high(sizeof(*myval) * 2);
> +myval[0] = 0x1234abcd;
> +myval[1] = 0xdcba8976;
> +
> +// build "OperationRegion(BDAT, SystemMemory, 0x12345678, 0x87654321)"
> +*(ssdt_ptr++) = 0x5B; // ExtOpPrefix
> +*(ssdt_ptr++) = 0x80; // OpRegionOp
> +*(ssdt_ptr++) = 'B';
> +*(ssdt_ptr++) = 'D';
> +*(ssdt_ptr++) = 'A';
> +*(ssdt_ptr++) = 'T';
> +*(ssdt_ptr++) = 0x00; // SystemMemory
> +*(ssdt_ptr++) = 0x0C; // DWordPrefix
> +*(u32*)ssdt_ptr = (u32)myval;
> +ssdt_ptr += 4;
> +*(ssdt_ptr++) = 0x0C; // DWordPrefix
> +*(u32*)ssdt_ptr = sizeof(*myval)*2;
> +ssdt_ptr += 4;
> +
> build_header((void*)ssdt, SSDT_SIGNATURE, ssdt_ptr - ssdt, 1);
>
> //hexdump(ssdt, ssdt_ptr - ssdt);
--
Gleb.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
