Re: [SeaBIOS] About cpu_set, CPU hotplug and related subjects
On 28.04.2010 12:45, Gleb Natapov wrote: > On Wed, Apr 28, 2010 at 12:41:51PM +0200, Jes Sorensen wrote: > >> The CPU declarations are particularly tricky as they get pretty big and >> complex and need to live in the DSDT, whereas a lot of other things we >> can shift off to separate SSDT tables and only put the minimum that >> needs to be generated dynamically in it's own table. >> >> > We can generate complex code statically and call it from dynamically > generated CPU declarations. > There is some ACPI code generator in coreboot. Not sure if it is usable for those purposes. coreboot uses it to generate AMD CPU frequency tables. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
On 30.09.2009 15:07, Anthony Liguori wrote: > Carl-Daniel Hailfinger wrote: >> However, to run coreboot on Qemu with the same init sequence as on >> simplified real hardware, we need Cache-as-RAM (CAR) support. [...] > > Do we really need coreboot to use the same init sequence? coreboot > is firmware and we don't necessarily run real firmware under QEMU. > It's a short cut that lets us avoid a lot of complexity. I know that some people were running 440BX BIOS images for real hardware on Qemu and they got pretty far. The complexity would be limited to the MTRR code and unless there were major architectural changes in mapping RAM to address ranges, no other code (except VM save and VM restore) should get even a single line changed. >> Right now coreboot sets up the MTRRs correctly, but then (conditional on >> Qemu) only uses areas which are known to be backed by RAM instead of the >> areas designated by CAR. >> >> I'd like to implement CAR support which builds on top of my MTRR code >> which was merged some months ago (and I already have code to check for >> total cacheable area size), but I need help with the memory mapping >> stuff. How do I proceed? Clean up what I have and insert "FIXME" >> comments where I don't know how to implement stuff so others can see the >> code and comment on it? > > You could start there. But from a higher level, I'm not sure I think > a partial implementation of something like CAR is all that valuable > since coreboot already runs under QEMU. It only runs if WORKAROUND_QEMU is defined (maybe not exactly that name, but you get the point). The code in coreboot calculates MTRR settings to cover the place where the stack will be. To workaround missing CAR in Qemu, it then has to recalculate the stack location to be able to actually use the stack. That forces coreboot to keep two stack base variables and to completely replace the generic logic which switches off CAR. I hope the explanation above didn't offend you, I just tried to clarify why working CAR is such a big deal for coreboot. If you want either a full CAR implementation or no CAR implementation, I can write a patch which implements full CAR, but then I need to hook WBINVD, INVD and CLFLUSH. Neither instruction is executed often enough to show up in any profile. Besides that, for anything not using CAR (everything after the firmware), the penalty is a simple test of a boolean variable per WBINVD/INVD/CLFLUSH. If you have further questions, please don't hesitate to ask. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Release plan for 0.12.0
Hi, On 30.09.2009 01:54, Anthony Liguori wrote: > Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. > > I'd also like to try to enumerate some features for this release. > Here's a short list of things I expect to see for this release > (target-i386 centric). > > o switch to SeaBIOS (need to finish porting features from Bochs) That switch is much appreciated because it also reduces the testing matrix of those coreboot developers who boot test every commit with Qemu. However, to run coreboot on Qemu with the same init sequence as on simplified real hardware, we need Cache-as-RAM (CAR) support. This is basically a mode where sizeof(cacheable area) <= sizeof (L2 cache) and causes the processor to lock the cache and not pass any reads/writes through to the RAM behind the cached area. The easiest way to implement this would be to check the cache size criterion upon every MTRR manipulation and either map a chunk of fresh memory on top of the existing memory (which may be RAM, ROM or unmapped) for every cacheable area, and if the cacheable area starts to exceed the L2 cache size, discard all memory contents of the memory mapped on top. For additional correctness, the memory shoud not be discarded and written back to the lower layer of memory if WBINVD (instead of INVD) or CLFLUSH are called. That one is mostly sugar, though, and coreboot can do without. Right now coreboot sets up the MTRRs correctly, but then (conditional on Qemu) only uses areas which are known to be backed by RAM instead of the areas designated by CAR. I'd like to implement CAR support which builds on top of my MTRR code which was merged some months ago (and I already have code to check for total cacheable area size), but I need help with the memory mapping stuff. How do I proceed? Clean up what I have and insert "FIXME" comments where I don't know how to implement stuff so others can see the code and comment on it? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCI device passthrough for FreeDOS guests
Hi, I want to trace the PCI device accesses (config space, I/O ports, memory BARs) of a DOS application (EEPROM flasher) and it seems KVM can help with this. The current plan is to install KVM, use FreeDOS as a guest, activate passthrough for the PCI device I'm interested in and log the accesses somehow. Possible problems I'd have to solve: - According to http://www.linux-kvm.org/wiki/images/d/d0/KvmForum2008$kdf2008_14.pdf PCI device passthrough needs a CPU with VT-d/IOMMU support. - http://www.linux-kvm.org/page/TODO says passthrough won't work for conventional PCI devices (I assume a PCI graphics card is such a device). - http://www.linux-kvm.org/page/TODO says passthrough won't work for devices without Function Level Reset (FLR). - http://www.linux-kvm.org/page/TODO says VT support for real mode is not good, so FreeDOS might be a problem. - The KVM wiki does not mention how to get PCI passthrough working. - No idea if logging of PCI accesses is possible with KVM or if I have to use helper tools for that. Any insights/hints are appreciated. If KVM is the wrong tool for my task, please point me in the right direction. Please CC me as I'm not subscribed to the list. Thanks. Regards, Carl-Daniel P.S. The linux-kvm.org wiki returns zero results if you search the wiki text for "PCI", but a Google search finds quite a few pages mentioning PCI. Is there a bug in the seach function? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
On 17.12.2008 14:55, Gleb Natapov wrote: > On Wed, Dec 17, 2008 at 02:45:38PM +0100, Jan Kiszka wrote: > >> Paul Brook wrote: >> > Modern BIOSes have splash screens. I don't see why our BIOS shouldn't > have one too. > Crap PC BIOSes have splash screens because they're horribly slow and otherwise printing lots of irrelevant scary junk at users. The best BIOS 'splash' screen is one which never appears unless there is a boot failure, and gets control to the OS as quickly as possible. IMHO a better goal is reducing the time until the OS / bootloader is able to take over all management of the display. >>> I agree. The qemu bios init process takes almost no time. >>> >>> The only reason it takes a noticeable amount of time is that we have a >>> deliberate delay in there to allow the user to access the boot menu. >>> I'm not convinced this menu is actually very useful in practice, It's >>> something that should probably be delegated to your management utility >>> and/or >>> be optional. >>> >> Yes, please. I hate this artificial delay, specifically as I have to do >> a lot of short boot tests where this contributes noticeably to their >> execution time. But, as usual, it didn't hurt enough to make me hack a >> patch yet. I'm willing to do this if we can agree on how it should be done. >> >> > Add "-bootmenu" option to qmeu and pass it to BIOS via fw confing interface? > If you pick NVRAM (RTC battery data storage) for this config item, traditional BIOS and coreboot and EFI and OFW can pick it up without problems. Plus, it is the traditional way to store splash screen settings. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
On 17.12.2008 14:09, Laurent Vivier wrote: > Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a > écrit : > >> On 16.12.2008 22:51, Laurent Vivier wrote: >> >>> Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : >>> >>> >>>> On 12/16/08, Anthony Liguori wrote: >>>> >>>> >>>>> Blue Swirl wrote: >>>>> >>>>> >>> >>> >>>>>> The control channel may still be needed. >>>>>> >>>>>> Alternatively the BIOS could load the image and fade parameters from a >>>>>> new ROM or from the configuration device and draw it to screen. This >>>>>> would need some PNG support to BIOS, or that the image stored in raw >>>>>> form. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yeah, having QEMU render to the VGA directly is a bit ugly. It would be >>>>> nicer if the BIOS actually rendered the image but I'm not sure I think we >>>>> should reject the patch just because it doesn't. >>>>> >>>>> >>>> Actually this way the image can be in full color even if the emulated >>>> device was an EGA in text mode. >>>> >>>> >>> And you can provide the image name on the command line, and complexity >>> is in Qemu, not in BIOS. >>> >>> >> If one of the goals of QEMU is to be somewhat similar to hardware, this >> should be done in the BIOS. >> > > A lot of things in Qemu are already not similar to hardware: virtio, > firmware configuration device, instruction timing... > > >> What happens if the BIOS provides a splash screen? Will it override the >> QEMU splash screen? >> > > Yes. The BIOS asks Qemu to display the image... or not. > What happens if you run a native BIOS/EFI/whatever for the hardware emulated in QEMU? Some people try to do exactly that. >>> But in fact, my first idea was to read the image data from the >>> configuration device (which is always possible with LOGO_CMD_OFFSET), >>> but when I saw how it has been done in VirtualBox, I though it was a >>> good idea. >>> >>> >> Modern x86 BIOSes read the splash screen from the BIOS ROM and the >> settings from NVRAM (sometimes the BIOS ROM is used for that as well by >> reflashing a sector of the ROM on every boot). >> > > A BIOS, by definition, is not modern... ;-) > Agreed. > (Openfirmware is...) > Even EFI is more modern than OpenFirmware. However, the most important question here is how you quantify modernness ;-) Speaking as a coreboot (really modern x86 firmware) developer, I'd like to keep the number of workarounds for QEMU hardware quirks to a minimum. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
On 16.12.2008 22:51, Laurent Vivier wrote: > Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : > >> On 12/16/08, Anthony Liguori wrote: >> >>> Blue Swirl wrote: >>> > > The control channel may still be needed. Alternatively the BIOS could load the image and fade parameters from a new ROM or from the configuration device and draw it to screen. This would need some PNG support to BIOS, or that the image stored in raw form. >>> Yeah, having QEMU render to the VGA directly is a bit ugly. It would be >>> nicer if the BIOS actually rendered the image but I'm not sure I think we >>> should reject the patch just because it doesn't. >>> >> Actually this way the image can be in full color even if the emulated >> device was an EGA in text mode. >> > > And you can provide the image name on the command line, and complexity > is in Qemu, not in BIOS. > If one of the goals of QEMU is to be somewhat similar to hardware, this should be done in the BIOS. What happens if the BIOS provides a splash screen? Will it override the QEMU splash screen? > But in fact, my first idea was to read the image data from the > configuration device (which is always possible with LOGO_CMD_OFFSET), > but when I saw how it has been done in VirtualBox, I though it was a > good idea. > Modern x86 BIOSes read the splash screen from the BIOS ROM and the settings from NVRAM (sometimes the BIOS ROM is used for that as well by reflashing a sector of the ROM on every boot). Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
