Re: KVM cpu limitations
On Tue, Aug 09, 2011 at 02:32:02PM -0400, John Paul Walters wrote: > I've enabled debugging in seabios (#define DEBUG_BIOS) and get the > output below. Note that with the help of folks in the KVM irc > channel I'm able to start a 254 core instance using the KVM tool, so > the problem seems to be limited to qemu/seabios. [...] > jwalters@uv /tmp/qemu_test_jp $ /opt/qemu.git/bin/qemu-system-x86_64 -smp 84 > -drive file=big_image_2.qcow2,if=virtio -m 8388 > Found 84 cpu(s) max supported 84 cpu(s) > MP table addr=0x000fd4b0 MPC table addr=0x000fd4c0 size=1892 > SMBIOS ptr=0x000fd490 table=0xd030 > ACPI tables: RSDP=0x000fd460 RSDT=0xdfffa5c0 [...] > WARNING - Unable to allocate resource at init_virtio_blk:107! > WARNING - Unable to allocate resource at init_atadrive:740! You're hitting a weird interaction with the mptable - its allocation just barely fits, and since it takes up all the ram in the f-segment it causes other allocations to fail (which are needed to hold info on the boot drive). This should no longer be an issue in the latest SeaBIOS from git. Alternatively, if you increase the number of CPUs, you should see the machine boot becuase only the mptable allocation will fail. -Kevin -- 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: [PATCH] add acpi pmtimer support
On Mon, Aug 13, 2012 at 03:04:10PM +0200, Gerd Hoffmann wrote: > This patch makes seabios use the acpi pmtimer instead of tsc for > timekeeping. The pmtimer has a fixed frequency and doesn't need > calibration, thus it doesn't suffer from calibration errors due to a > loaded host machine. It looks okay to me. It'd be nice to have a CONFIG_PMTIMER for it, but it can be added on top. -Kevin -- 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] Big real mode use in ipxe
On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote: > ipxe contains the following snippet: > > /* Copy ROM to image source PMM block */ > pushw %es > xorw%ax, %ax > movw%ax, %es > movl%esi, %edi > xorl%esi, %esi > movzbl romheader_size, %ecx > shll$9, %ecx > addr32 rep movsb/* PMM presence implies flat real mode */ > > Which copies an image to %edi, with %edi >= 0x1. This is in accordance > with the PMM spec: [...] > So far so good. But the Intel SDM says (20.1.1): > > "The IA-32 processors beginning with the Intel386 processor can generate > 32-bit offsets using an address override prefix; however, in real-address > mode, the value of > a 32-bit offset may not exceed H without causing an exception. For full > compatibility with Intel 286 real-address mode, pseudo-protection faults > (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range > 0 through H." I interpretted the above to mean "however, in [normal real-mode where the segment registers are set to 0x] real-address mode, the value of a 32-bit offset may not exceed H without causing an exception" > Which is exactly what happens here. My understanding of big real > mode is that to achieve a segment limit != 0x, you must go into > 32-bit protected mode, load a segment with a larger limit, and > return into real mode without touching the segment. The next load > of the segment will reset the limit to 0x. No, the segment limit is only changed when the protected mode bit is set and the segment register is loaded. When the protected mode bit is not set, only the segment offset changes. [...] > The PMM spec also has this to say (1.3): > > "Big Real Mode > > Big Real Mode is a modified version of the processor’s real mode > with the segment limits changed from 1MB to 4GB. Big real mode > allows the BIOS or an Option ROM to read and write extended memory > without the overhead of protected mode. The BIOS puts the processor > in big real mode during POST to allow simplified access to extended > memory. The processor will be in big real mode while the PMM > Services are callable." > > This is more in line with the Intel spec, and means that the > modification to %es must be avoided (and that seabios needs changes > to either work in big real mode, or to put the processor back into > big real mode after returning from a PMM service. The SeaBIOS code is regularly used on a variety of real processors (which do enforce segment limits). This includes several different AMD processors and Intel processors. It has also been tested in the past with other manufacturers (eg, Via). We've never seen an issue with the "big real mode" support. > The whole thing is very unfortunate, as kvm is very slow while in > big real mode, on certain processors. Unfortunately, "big real mode" is a requirement for option roms. -Kevin -- 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] [ipxe-devel] Big real mode use in ipxe
On Sun, Aug 19, 2012 at 04:34:50PM +0100, Michael Brown wrote: > On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote: > > (and that seabios needs changes to either work in > > big real mode, or to put the processor back into big real mode after > > returning from a PMM service. > > If seabios switches into protected mode when performing a PMM service, then > it > _must_ leave the segment limits at 4G when returning to real mode. To do > otherwise will violate the PMM spec, and will break conforming clients such > as > iPXE. SeaBIOS does switch to 32bit mode during PMM calls and does switch to 16bit "big real" mode (segment limits set to 4G) on return. -Kevin -- 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: [PATCH v2] add acpi pmtimer support
On Tue, Aug 14, 2012 at 07:29:19AM +0200, Gerd Hoffmann wrote:
> This patch makes seabios use the acpi pmtimer instead of tsc for
> timekeeping. The pmtimer has a fixed frequency and doesn't need
> calibration, thus it doesn't suffer from calibration errors due to a
> loaded host machine.
The patch looks okay to me, but is it still needed? (I recall seeing
something on the kvm list about a bug fix to the main timer.)
[...]
> +static u64 pmtimer_get(void)
> +{
> +u16 ioport = GET_GLOBAL(pmtimer_ioport);
> +u32 wraps = GET_LOW(pmtimer_wraps);
> +u32 pmtimer = inl(ioport);
> +
> +if (pmtimer < GET_LOW(pmtimer_last)) {
> +wraps++;
> +SET_LOW(pmtimer_wraps, wraps);
> +}
> +SET_LOW(pmtimer_last, pmtimer);
> +
> +dprintf(9, "pmtimer: %u:%u\n", wraps, pmtimer);
> +return (u64)wraps << 24 | pmtimer;
BTW, why is this "<< 24", and if it should be that way, shouldn't the
pmtimer be "inl(ioport) & 0xff" ?
-Kevin
--
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: HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)
On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote: > On 2011-08-28 20:54, Alexander Graf wrote: > > > > On 28.08.2011, at 02:42, Avi Kivity wrote: > > > >> On 08/26/2011 08:32 AM, ya su wrote: > >>> hi,Avi: > >>> > >>> I met the same problem, tons of hpet vm_exits(vector 209, fault > >>> address is in the guest vm's hpet mmio range), even I disable hpet > >>> device in win7 guest vm, it still produce a larget amount of vm_exits > >>> when trace-cmd ; I add -no-hpet to start the vm, it still has HPET > >>> device inside VM. > >>> > >>> Does that means the HPET device in VM does not depend on the > >>> emulated hpet device in qemu-kvm? Is there any way to disable the VM > >>> HPET device to prevent so many vm_exits? Thansk. > >>> > >> > >> Looks like a bug to me. > > > > IIRC disabling the HPET device doesn't remove the entry from the DSDT, no? > > So the guest OS might still think it's there while nothing responds (read > > returns -1). > > Exactly. We have a fw_cfg interface in place for quite a while now > (though I wonder how the firmware is supposed to tell -no-hpet apart > from QEMU versions that don't provide this data - both return count = > 255), but SeaBios still exposes one HPET block at a hard-coded address > unconditionally. > > There was quite some discussion about the corresponding Seabios patches > back then but apparently no consensus was found. Re-reading it, I think > Kevin asked for passing the necessary DSDT fragments from QEMU to the > firmware instead of using a new, proprietary fw_cfg format. Is that > still the key requirement for any patch finally fixing this bug? My preference would be to use the existing ACPI table passing interface (fw_cfg slot 0x8000) to pass different ACPI tables to SeaBIOS. SeaBIOS doesn't currently allow that interface to override tables SeaBIOS builds itself, but it's a simple change to rectify that. When this was last proposed, it was raised that the header information in the ACPI table may then not match the tables that SeaBIOS builds. I think I proposed at that time that SeaBIOS could use the header of the first fw_cfg table (or some other fw_cfg interface) to populate the headers of its table headers. However, there was no consensus. Note - the above is in regard to the HPET table. If the HPET entry in the DSDT needs to be removed then that's a bigger change. -Kevin -- 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: [PATCH] pci: clean all funcs when hot-removing multifunc device
On Wed, Sep 14, 2011 at 07:45:59AM -0400, Amos Kong wrote:
> The size of bios.bin compiled from seabios
> original: 128K
> only apply patch1: 256K
> only apply patch2: 128K
>
> patch1: add 6 slot(only slot6 has 8 funcs) to the table
> can hotplug/hot-remove a multifunc device to slot 6 successfully
>
> patch2: add 31 slot(with 8 funcs) to the table
> could not boot up guest.
> I found there is a special process for large bios.bin in qemu,
> problem maybe exist here, I'm driving into it...
>
> qemu/hw/pc.c:
> void pc_memory_init(...
>
> /* map the last 128KB of the BIOS in ISA space */
> isa_bios_size = bios_size;
> if (isa_bios_size > (128 * 1024))
> isa_bios_size = 128 * 1024;
This is probably a regression since seabios commit 87b533bf. Prior to
that commit, seabios did not mark the early 32bit initialization code
as init code. However, a side effect of marking that code
(handle_post) as init code is that it is more likely the linker could
place the code at an address less than 0xe.
I'm guesing the patch below (just a hack) would cover up the issue.
-Kevin
--- a/src/post.c
+++ b/src/post.c
@@ -336,7 +336,7 @@ reloc_init(void)
// Start of Power On Self Test (POST) - the BIOS initilization phase.
// This function does the setup needed for code relocation, and then
// invokes the relocation and main setup code.
-void VISIBLE32INIT
+void VISIBLE32FLAT
handle_post(void)
{
debug_serial_setup();
@@ -356,6 +356,14 @@ handle_post(void)
// Allow writes to modify bios area (0xf)
make_bios_writable();
+
+void handle_post2(void);
+handle_post2();
+}
+
+void VISIBLE32INIT
+handle_post2(void)
+{
HaveRunPost = 1;
// Detect ram and setup internal malloc.
--
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: [SeaBIOS PATCH v2] Fix regression of commit 87b533bf
On Tue, Sep 20, 2011 at 04:00:57AM -0400, Amos Kong wrote: > From 4678a3cb0e0a3cd7a4bc3d284c5719fdba90bc61 Mon Sep 17 00:00:00 2001 > From: Kevin O'Connor > Date: Tue, 20 Sep 2011 15:43:55 +0800 > Subject: [PATCH V2] Fix regression of commit 87b533bf > > From: Kevin O'Connor > > After adding more device entries in ACPI DSDT tables, > the filesize of bios.bin changed from 128K to 256K. > But bios could not initialize successfully. > > This is a regression since seabios commit 87b533bf. Prior to > that commit, seabios did not mark the early 32bit initialization > code as init code. However, a side effect of marking that code > (handle_post) as init code is that it is more likely the linker > could place the code at an address less than 0xe. > The patch (just a hack) would cover up the issue. Thanks. I committed a slightly different patch (but similar concept) to the seabios repo. -Kevin -- 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: [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI DSDT tables
On Tue, Sep 20, 2011 at 06:45:57AM -0400, Amos Kong wrote:
> From 48ea1c9188334b89a60b4f9e853e86fc04fda4a5 Mon Sep 17 00:00:00 2001
> From: Amos Kong
> Date: Tue, 20 Sep 2011 15:38:43 +0800
> Subject: [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI DSDT tables
>
> Only func 0 is registered to guest driver (we can
> only found func 0 in slot->funcs list of driver),
> the other functions could not be cleaned when
> hot-removing the whole slot. This patch adds
> device per function in ACPI DSDT tables.
>
> Have tested with linux/winxp/win7, hot-adding/hot-remving,
> single/multiple function device, they are all fine.
> ---
> Changes from v1:
> - cleanup the macros, bios.bin gets back to 128K
> - notify only when func0 is added and removed
How about moving code into functions so that it isn't duplicated for
each PCI device. See the patch below as an example (100% untested).
The CPU hotplug stuff works this way, except it run-time generates the
equivalent of "Device(S???)" and "PCNT". (It may make sense to
run-time generate the PCI hotplug as well - it consumes about 10K of
space to statically generate the 31 devices.)
-Kevin
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 08412e2..31ac5eb 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -128,48 +128,6 @@ DefinitionBlock (
PCRM, 32,
}
-#define hotplug_slot(name, nr) \
-Device (S##name) {\
- Name (_ADR, nr##) \
- Method (_EJ0,1) { \
-Store(ShiftLeft(1, nr), B0EJ) \
-Return (0x0) \
- } \
- Name (_SUN, name) \
-}
-
- hotplug_slot(1, 0x0001)
- hotplug_slot(2, 0x0002)
- hotplug_slot(3, 0x0003)
- hotplug_slot(4, 0x0004)
- hotplug_slot(5, 0x0005)
- hotplug_slot(6, 0x0006)
- hotplug_slot(7, 0x0007)
- hotplug_slot(8, 0x0008)
- hotplug_slot(9, 0x0009)
- hotplug_slot(10, 0x000a)
- hotplug_slot(11, 0x000b)
- hotplug_slot(12, 0x000c)
- hotplug_slot(13, 0x000d)
- hotplug_slot(14, 0x000e)
- hotplug_slot(15, 0x000f)
- hotplug_slot(16, 0x0010)
- hotplug_slot(17, 0x0011)
- hotplug_slot(18, 0x0012)
- hotplug_slot(19, 0x0013)
- hotplug_slot(20, 0x0014)
- hotplug_slot(21, 0x0015)
- hotplug_slot(22, 0x0016)
- hotplug_slot(23, 0x0017)
- hotplug_slot(24, 0x0018)
- hotplug_slot(25, 0x0019)
- hotplug_slot(26, 0x001a)
- hotplug_slot(27, 0x001b)
- hotplug_slot(28, 0x001c)
- hotplug_slot(29, 0x001d)
- hotplug_slot(30, 0x001e)
- hotplug_slot(31, 0x001f)
-
Name (_CRS, ResourceTemplate ()
{
WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
@@ -762,6 +720,119 @@ DefinitionBlock (
Zero /* reserved */
})
+/* PCI hotplug */
+Scope(\_SB.PCI0) {
+/* Methods called by bulk generated PCI devices below */
+Method (PCEJ, 1, NotSerialized) {
+// _EJ0 method - eject callback
+Store(ShiftLeft(1, Arg0), B0EJ)
+Return (0x0)
+}
+
+/* Bulk generated PCI hotplug devices */
+#define hotplug_func(nr, fn)\
+Device (S##nr##fn) {\
+Name (_ADR, 0x##nr##000##fn)\
+Method (_EJ0, 1) { Return(PCEJ(0x##nr)) } \
+Name (_SUN, 0x##nr) \
+}
+
+#define hotplug_slot(nr) \
+hotplug_func(nr, 0) \
+hotplug_func(nr, 1) \
+hotplug_func(nr, 2) \
+hotplug_func(nr, 3) \
+hotplug_func(nr, 4) \
+hotplug_func(nr, 5) \
+hotplug_func(nr, 6) \
+hotplug_func(nr, 7)
+
+ hotplug_slot(01)
+ hotplug_slot(02)
+ hotplug_slot(03)
+ hotplug_slot(04)
+ hotplug_slot(05)
+ hotplug_slot(06)
+ hotplug_slot(07)
+ hotplug_slot(08)
+ hotplug_slot(09)
+ hotplug_slot(0a)
+ hotplug_slot(0b)
+ hotplug_slot(0c)
+ hotplug_slot(0d)
+ hotplug_slot(0e)
+ hotplug_slot(0f)
+ hotplug_slot(10)
+ hotplug_slot(11)
+ hotplug_slot(12)
+ hotplug_slot(13)
+ hotplug_slot(14)
+ hotplug_slot(15)
+ hotplug_slot(16)
+ hotplug_slot(17)
+ hotplug_slot(18)
+ hotplug_slot(19)
+ hotplug_slot(1a)
+ hotplug_slot(1b)
+ hotplug_slot(1c)
+ hotplug_slot(1d)
+ hotplug_slot(1e)
+ hotplug_slot(1f)
+
+/* PCI hotplug notify method */
+Method(PCNF, 0) {
+// Local0 = iterator
+
Re: [SeaBIOS PATCH v2] hotplug: Add device per func in ACPI DSDT tables
On Wed, Sep 21, 2011 at 02:09:08PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote:
> > - Original Message -
> > > How about moving code into functions so that it isn't duplicated for
> > > each PCI device. See the patch below as an example (100% untested).
>
> Hmm, I sent patches that did a similar thing but
> in a slightly more compact way.
> Message ids:
> 20110919092932.gb4...@redhat.com
> 20110919093644.gc4...@redhat.com
> 20110919100434.ga6...@redhat.com
>
> Did they not reach you or something's wrong with them?
I received them, but when I saw Amos' v2 patch I thought he included
them.
> > > +/* Bulk generated PCI hotplug devices */
> > > +#define hotplug_func(nr, fn)\
> > > +Device (S##nr##fn) {\
> > > +Name (_ADR, 0x##nr##000##fn)\
> > > +Method (_EJ0, 1) { Return(PCEJ(0x##nr)) } \
> > > +Name (_SUN, 0x##nr) \
> > > +}
>
> The fundamental question is still why would
> we have _EJ0 methods in functions >0 when they are
> not individually hotpluggable.
> I think only function 0 should have _EJ0.
I don't know the answer to this question.
Maybe we should just collapse the current definitions and then put the
fixes and enhancements on top of the collapsed version.
-Kevin
--
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: [PATCH 0/4] acpi: fix up EJ0 in DSDT
On Wed, Sep 21, 2011 at 03:44:13PM +0300, Michael S. Tsirkin wrote: > The reason is that our acpi tables declare both _RMV with value 0, > and _EJ0 method for these slots. What happens in this case > is undocumented by ACPI spec, so linux ignores _RMV, > and windows seems to ignore _EJ0. Could the DSDT just not define _EJ0 for device 1 & 2 instead of dynamically patching them? (Would there ever be a case where we wouldn't know at compile time which devices need _EJ0?) > The correct way to suppress hotplug is not to have _EJ0, > so this is what this patch does: it probes PIIX and > modifies DSDT to match. The code to generate basic SSDT code isn't that difficult (see build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to patch the DSDT versus just generating the necessary blocks in an SSDT? -Kevin -- 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: [PATCH 0/4] acpi: fix up EJ0 in DSDT
On Thu, Sep 22, 2011 at 09:09:49AM +0300, Michael S. Tsirkin wrote: > On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote: > > On Wed, Sep 21, 2011 at 03:44:13PM +0300, Michael S. Tsirkin wrote: > > > The correct way to suppress hotplug is not to have _EJ0, > > > so this is what this patch does: it probes PIIX and > > > modifies DSDT to match. > > > > The code to generate basic SSDT code isn't that difficult (see > > build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to > > patch the DSDT versus just generating the necessary blocks in an SSDT? > > I don't really care whether the code is in DSDT or SSDT, > IMO there isn't much difference between build_ssdt and patching: > main reason is build_ssdt uses offsets hardcoded to a specific binary > (ssdt_proc and SD_OFFSET_* ) while I used > a script to extract offsets. > > I think we should avoid relying on copy-pasted binary > because I see the related ASL code changing in the near future > (with multifunction and bridge support among others). > > I can generalize the approach though, so that > it can work for finding arbitrary names > without writing more scripts, hopefully with the > potential to address the hard-coded offsets in acpi.c > as well. Does that sound interesting? Replacing the hardcoding of offsets in src/ssdt-proc.dsl would be nice. I'll take a look at your new patches tonight. -Kevin -- 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: [PATCH 0/4] acpi: fix up EJ0 in DSDT
On Thu, Sep 22, 2011 at 09:09:49AM +0300, Michael S. Tsirkin wrote: > On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote: > > The code to generate basic SSDT code isn't that difficult (see > > build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to > > patch the DSDT versus just generating the necessary blocks in an SSDT? > > I don't really care whether the code is in DSDT or SSDT, > IMO there isn't much difference between build_ssdt and patching: > main reason is build_ssdt uses offsets hardcoded to a specific binary > (ssdt_proc and SD_OFFSET_* ) while I used > a script to extract offsets. Yes - your script to extract the offsets is nice. > I think we should avoid relying on copy-pasted binary > because I see the related ASL code changing in the near future > (with multifunction and bridge support among others). Can you expand on this? Would multi-function and bridge support make patching easier than dynamic SSDT generation? I'm a little leary of patching the DSDT - doubly so when the DSDT is creating dummy devices that are then dynamically patched out. (For example, even with your patch series there are still two devices defined with _ADR 1.) It seems more straight-forward to just create the devices that are needed. -Kevin -- 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: [PATCH 0/4] acpi: fix up EJ0 in DSDT
On Mon, Sep 26, 2011 at 10:04:13AM +0300, Michael S. Tsirkin wrote: > On Mon, Sep 26, 2011 at 12:40:18AM -0400, Kevin O'Connor wrote: > > On Thu, Sep 22, 2011 at 09:09:49AM +0300, Michael S. Tsirkin wrote: > > > On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote: > > > > The code to generate basic SSDT code isn't that difficult (see > > > > build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to > > > > patch the DSDT versus just generating the necessary blocks in an SSDT? > > > > > > I don't really care whether the code is in DSDT or SSDT, > > > IMO there isn't much difference between build_ssdt and patching: > > > main reason is build_ssdt uses offsets hardcoded to a specific binary > > > (ssdt_proc and SD_OFFSET_* ) while I used > > > a script to extract offsets. > > > > Yes - your script to extract the offsets is nice. > > If you still have doubts, > it might make sense to merge just patch 1 - > acpi: generate and parse mixed asl/aml listing > - as the first step. > With the infrastructure in place it will be > easier to discuss the best way to use it. I'm okay with your first patch. However, I wish to tag a release before committing ACPI changes. There was a concern raised with two-pass PCI initialization that I need to follow up on before tagging. -Kevin -- 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: [PATCHv3 4/4] acpi: automatically generated ssdt proc
On Tue, Oct 04, 2011 at 03:26:19PM +0200, Michael S. Tsirkin wrote:
> Get rid of manually cut and pasted ssdt_proc,
> use ssdt compiled by iasl and offsets extracted
> by acpi_extract instead.
Thanks - I like the idea of auto-generating the offsets.
[...]
> +#define AmlCode static ssdp_proc_aml
> +#include "ssdt-proc.hex"
> +#undef AmlCode
Side note - since you're post-processing the acpi data, it would be
nice to update the name in the hex file too.
> +/* 0x5B 0x83 ProcessorOp PkgLength NameString ProcID */
> +#define SD_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2)
> +#define SD_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4)
> +#define SD_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start)
> +#define SD_SIZEOF (*ssdt_proc_end - *ssdt_proc_start)
> +#define SD_PROC (ssdp_proc_aml + *ssdt_proc_start)
[...]
> DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC", "BXSSDT", 0x1)
> -/* v-- DO NOT EDIT --v */
> {
> +ACPI_EXTRACT_PROCESSOR_START ssdt_proc_start
> +ACPI_EXTRACT_PROCESSOR_END ssdt_proc_end
> +ACPI_EXTRACT_PROCESSOR_STRING ssdt_proc_name
> Processor (CPAA, 0xAA, 0xb010, 0x06) {
Since the acpi.c code needs to know the processor object format
anyway, what about making a generic "ACPI_EXTRACT" indicator that
exports the location, size, and parameter location in one go.
Something like:
ACPI_EXTRACT ssdt_proc_obj
Processor (CPAA, 0xAA, 0xb010, 0x06) {
which would produce something like:
static struct aml_object ssdt_proc_obj = {.addr=0x24, .size=0x40, .param=0x28};
As for the other parts of this patch series - I'm still leary of
changing the DSDT dynamically. I'd be curious to see if we can add
the following to ssdt-proc.dsl:
ACPI_EXTRACT hotplug_obj
Device (SL00) {
ACPI_EXTRACT_NAME_DWORD_CONST hotplog_id
Name (ID, 0xAABBCCDD)
Name (_ADR, ID)
Method (_EJ0, 1) { Return(PCEJ(ID)) }
Name (_SUN, ID)
}
and then just memcpy the "hotplug_obj" N number of times into the ssdt
for each available slot. (This would be on top of the DSDT
simplification patch series that I posted previously.)
-Kevin
--
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: [PATCHv3 4/4] acpi: automatically generated ssdt proc
On Wed, Oct 05, 2011 at 08:35:26AM -0200, Michael S. Tsirkin wrote:
> On Tue, Oct 04, 2011 at 10:52:33PM -0400, Kevin O'Connor wrote:
> > Something like:
> >
> > ACPI_EXTRACT ssdt_proc_obj
> > Processor (CPAA, 0xAA, 0xb010, 0x06) {
> >
>
> I considered this, sure. We could parse AML to figure out
> what is the object type we are trying to look up.
>
> However I decided sanity-checking that we get the right type of object
> in AML is better. This way if iasl output format breaks
> we will have a better chance to detect that.
> Makes sense?
Yes. I guess one could do ACPI_EXTRACT_PROCESSOR for the sanity
check.
> Also this can not be as generic as it seems: each type of
> object in AML bytecode is encoded slightly differently.
> So we would still have types of objects we support
> and types of object we don't.
Yes.
> > which would produce something like:
> >
> > static struct aml_object ssdt_proc_obj = {.addr=0x24, .size=0x40,
> > .param=0x28};
>
> What is the param offset here?
The location of the first byte of the parameters (the same as you had
for ssdt_proc_name). Normally, AML objects take the form:
. The is itself
of variable length, so passing in the start of the fixed parameters
would make manipulating the results easier.
> > As for the other parts of this patch series - I'm still leary of
> > changing the DSDT dynamically.
>
> Hmm, not sure I understand why. Could you explain pls?
Sure:
- The DSDT is big and has several cross-functional users. Patching up
the DSDT for hotplug when the DSDT also has unrelated stuff (eg,
mouse) seems ugly.
- The PCI hotplug stuff is generating a whole bunch of devices and the
dynamic code is effectively disabling the unwanted ones. It seems
nicer to dynamically generate the desired entries instead of bulk
generating and dynamically blanking.
- The CPU hotplug has similar requirements, but is implemented
differently - it generates the CPU objects dynamically. It's not
desirable to bulk generate the CPU objects and "blank" them
dynamically, because 255 CPU objects would noticeably increase
SeaBIOS' static size.
- Some time back there were patches floating around to pass the DSDT
into SeaBIOS via fw_cfg interface. Those patches never made it in
(I forget why), but the basic functionality seemed sound. Patching
the DSDT in SeaBIOS would seem to eliminate that possibility.
None of these would be road-blocks. However, they make me want to
consider other approaches.
> > and then just memcpy the "hotplug_obj" N number of times into the ssdt
> > for each available slot. (This would be on top of the DSDT
> > simplification patch series that I posted previously.)
>
> This assumes all devices are the same. But unfortunately this will not
> work for other devices such as VGA.
The VGA device can't be hotplugged, so I don't see why that would be
an issue.
-Kevin
--
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: [PATCHv3 4/4] acpi: automatically generated ssdt proc
On Tue, Oct 04, 2011 at 03:26:19PM +0200, Michael S. Tsirkin wrote: > Get rid of manually cut and pasted ssdt_proc, > use ssdt compiled by iasl and offsets extracted > by acpi_extract instead. > > Signed-off-by: Michael S. Tsirkin FYI - I pushed the "ACPI DSDT simplifications" series and patch 1 and 4 from this series. -Kevin -- 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: [SeaBIOS] [PATCHv3 4/4] acpi: automatically generated ssdt proc
On Tue, Oct 18, 2011 at 02:47:29AM +0900, Isaku Yamahata wrote: > On Wed, Oct 05, 2011 at 10:15:26PM -0400, Kevin O'Connor wrote: > > - Some time back there were patches floating around to pass the DSDT > > into SeaBIOS via fw_cfg interface. Those patches never made it in > > (I forget why), but the basic functionality seemed sound. Patching > > the DSDT in SeaBIOS would seem to eliminate that possibility. > > Maybe a bit late comment. > At that time, the patch for qemu-side was NOT merged. > Right now it is merged into the qemu upstream as > 104bf02eb50e080ac9d0de5905f80f9a09730154 > (It took very long time to draw attention from the maintainers. sigh.) > > Keven, if you like, I'm willing to rebase/resend it. Sure - if the qemu part is upstream, send the patch again. -Kevin -- 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: [PATCH] Set numa topology for max_cpus
On Wed, Oct 26, 2011 at 02:19:00PM +0200, Vasilis Liaskovitis wrote: > qemu-kvm passes numa/SRAT topology information for smp_cpus to SeaBIOS. > However > SeaBIOS always expects to setup max_cpus number of SRAT cpu entries > (MaxCountCPUs variable in build_srat function of Seabios). When qemu-kvm runs > with smp_cpus != max_cpus (e.g. -smp 2,maxcpus=4), Seabios will mistakenly use > memory SRAT info for setting up CPU SRAT entries for the offline CPUs. Wrong > SRAT memory entries are also created. This breaks NUMA in a guest. > Fix by setting up SRAT info for max_cpus in qemu-kvm. > > Signed-off-by: Vasilis Liaskovitis It looks okay to me, but I'd like to see an Ack from a QEmu or KVM maintainer. -Kevin -- 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: [PATCH RFC] acpi: extract aml from .lst
On Wed, Oct 26, 2011 at 11:28:02PM +0200, Michael S. Tsirkin wrote: > Add ACPI_EXTRACT_ALL_CODE directive, to support extracting > AML code from listing into a named array. Use that instead including C > file generated by iasl, this makes it possible to include multiple AML > tables without resorting to preprocessor tricks. > > Signed-off-by: Michael S. Tsirkin > > --- > > Kevin, you suggested something like the below, I think? Seems to work > but RFC since I didn't have time to test this properly. It looks okay to me (I didn't do any exhaustive tests either). It would be preferable if we didn't have to change the acpi-dsdt.dsl file though - that way users could still compile it with the iasl compiler directly. Can the output default to "AmlCode" if no directive is found? -Kevin -- 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: [PATCH RFC] acpi: extract aml from .lst
On Wed, Oct 26, 2011 at 11:28:02PM +0200, Michael S. Tsirkin wrote: > Add ACPI_EXTRACT_ALL_CODE directive, to support extracting > AML code from listing into a named array. Use that instead including C > file generated by iasl, this makes it possible to include multiple AML > tables without resorting to preprocessor tricks. Thanks - I applied this patch. -Kevin -- 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: [PATCH 2/2] seabios: fix mptable nmi entry (was: Re: [Qemu-devel] [PATCH] qemu: Fix inject-nmi)
On Mon, Oct 10, 2011 at 02:06:29PM +0800, Lai Jiangshan wrote: > From: Kenji Kaneshige > > In the current seabios MP table description, NMI is connected only to > BSP's LINT1. But usually NMI is connected to all the CPUs' LINT1 as > indicated in MP specification. This patch changes seabios MP table to > describe NMI is connected to all the CPUs' LINT1. Thanks - I applied both of these patches. -Kevin -- 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: [PATCH RFC] acpi: add ssdt for cpi hotplug
On Tue, Nov 01, 2011 at 09:11:40PM +0200, Michael S. Tsirkin wrote:
> So here's the plan: move all hotplug handling out
> to ssdt, this way it'll keep working even with a
> user-supplied dsdt. Next step we can patch
> this ssdt at runtime.
>
> There's little point in this change alone, so posting as RFC,
> will repost with the patching part when it's ready,
> posting now to present opportunity for early feedback.
>
[...]
> -OperationRegion(PCST, SystemIO, 0xae00, 0x08)
> -Field (PCST, DWordAcc, NoLock, WriteAsZeros)
> -{
> -PCIU, 32,
> -PCID, 32,
> -}
> -
> -OperationRegion(SEJ, SystemIO, 0xae08, 0x04)
> -Field (SEJ, DWordAcc, NoLock, WriteAsZeros)
> -{
> -B0EJ, 32,
> -}
> -
> -OperationRegion(RMVC, SystemIO, 0xae0c, 0x04)
> -Field(RMVC, DWordAcc, NoLock, WriteAsZeros)
> -{
> -PCRM, 32,
> -}
> -
[...]
> -Scope(\_SB.PCI0) {
> -/* Methods called by bulk generated PCI devices below */
> -Method (PRMV, 1, NotSerialized) {
> -// _RMV method - check if device can be removed
> -If (And(\_SB.PCI0.PCRM, ShiftLeft(1, Arg0))) {
> -Return (0x1)
> -}
> -Return (0x0)
> -}
[...]
> -/* Methods called by bulk generated hotplug devices below */
> -Method (PCEJ, 1, NotSerialized) {
> -// _EJ0 method - eject callback
> -Store(ShiftLeft(1, Arg0), B0EJ)
> -Return (0x0)
> -}
[...]
> -/* PCI hotplug notify method */
> -Method(PCNF, 0) {
> -// Local0 = iterator
> -Store (Zero, Local0)
> -While (LLess(Local0, 31)) {
> -Increment(Local0)
> -If (And(PCIU, ShiftLeft(1, Local0))) {
> -PCNT(Local0, 1)
> -}
> -If (And(PCID, ShiftLeft(1, Local0))) {
> -PCNT(Local0, 3)
> -}
> -}
> -Return(One)
> -}
[...]
> -Method(_L01) {
> -// PCI hotplug event
> -Return(\_SB.PCI0.PCNF())
> -}
Can we leave these parts in the DSDT and only move the bulk generated
stuff to the SSDT?
-Kevin
--
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: [PATCH RFC] acpi: add ssdt for cpi hotplug
On Wed, Nov 02, 2011 at 10:54:42AM +0200, Michael S. Tsirkin wrote: > On Tue, Nov 01, 2011 at 06:59:01PM -0400, Kevin O'Connor wrote: > > Can we leave these parts in the DSDT and only move the bulk generated > > stuff to the SSDT? > > > They can, but I thought one of the reasons we do the split > is to make it possible for users to supply their own DSDT? > If so creating calls from SSDT into DSDT would make this very fragile. I think it's reasonable to require that a user supplied DSDT still fill certain requirements. Keep in mind that the reason for the "user supplied" DSDT was for new platform (q35) development - not necessarily so each individual user could set their own. It's not great to have the DSDT and SSDT tied to each other. However, once RMV is removed, it's only two methods (PCNT supplied by the SSDT and PCEJ supplied by the DSDT). I do see the upside to moving it all to the SSDT - but that has the disadvantage of taking away the ability of a user supplied DSDT to tweak how the hotplug functions work. Also, we'd then want to redo CPU hotplug to be the same way. -Kevin -- 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: [SeaBIOS] [PATCH RFC] acpi: add ssdt for cpi hotplug
On Thu, Nov 03, 2011 at 09:04:57AM +0800, Wen Congyang wrote: > At 11/03/2011 08:30 AM, Kevin O'Connor Write: > > I think it's reasonable to require that a user supplied DSDT still > > fill certain requirements. Keep in mind that the reason for the "user > > supplied" DSDT was for new platform (q35) development - not > > necessarily so each individual user could set their own. > > I do not think it's reasonable to require that a user supplied DSDT still > fill certain requiements. Please elaborate on why. The dependency on the DSDT is a few methods (PCEJ, CPEJ, CPST, CPMA). Under what circumstances would it be difficult for these methods to be provided? > I think we should not use default SSDT if we use user supplied DSDT. > If we use user supplied DSDT, we should use user supplied SSDT too. That's possible. However, how do you plan to provide a DSDT that accounts for the dynamic nature of the virtual system configuration. A different qemu/kvm command line (which configures pci or cpu count) will then require a different DSDT. -Kevin -- 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: [PATCHv4 0/3] acpi: DSDT/SSDT runtime patching
On Sun, Nov 20, 2011 at 07:56:43PM +0200, Michael S. Tsirkin wrote: > Here's an updated revision of acpi runtime patching patchset. > Lightly tested. It looks good to me. -Kevin -- 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: [PATCHv4 0/3] acpi: DSDT/SSDT runtime patching
On Mon, Nov 21, 2011 at 10:22:22PM +0200, Michael S. Tsirkin wrote: > On Sun, Nov 20, 2011 at 04:08:59PM -0500, Kevin O'Connor wrote: > > On Sun, Nov 20, 2011 at 07:56:43PM +0200, Michael S. Tsirkin wrote: > > > Here's an updated revision of acpi runtime patching patchset. > > > Lightly tested. > > > > It looks good to me. > > > > -Kevin > > Run some linux and windows tests, things seem to work > smoothly. Pls apply. I committed this series. Thanks, -Kevin -- 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: [SeaBIOS PATCH v3] hotplug: Add device per func in ACPI DSDT tables
On Tue, Dec 06, 2011 at 07:32:55PM -0500, Amos Kong wrote: > - Original Message - > > On Tue, Dec 06, 2011 at 01:39:35PM +0800, Amos Kong wrote: > > > Only func 0 is registered to guest driver (we can > > > only found func 0 in slot->funcs list of driver), > > > the other functions could not be cleaned when > > > hot-removing the whole slot. This patch adds > > > device per function in ACPI DSDT tables. > > > Notify only when func0 is added and removed. > > > > > > Have tested with linux/winxp/win7, hot-adding/hot-remving, > > > single/multiple function device, they are all fine(all > > > added devices can be removed). > > > > > This includes some bits I wrote but this is not an ack > > of the patch yet :) > > > > I find it surprising that this works: a function > > has _EJ0 so would not guest expect that ejecting > > a single one will only remove it, and not all functions? > > Removing single func is not supported by specific, and current code > (qemu/kernel pci driver) process hot-remove with the whole slot. > We could not hot-remove single func with/without this patch. > > Register _EJ0() for each func, then all the funcs will be record > into the function list of the slot. Just as an update - it's not clear to me what this patch does, and it seems like Michael had some concerns. Also, it doesn't seem right to hardcode the generation of that many devices (248) in the AML code. So, unless there are further comments I'm going to hold off on this patch. -Kevin -- 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: [PATCH 1/3][Seabios] Add bitmap for cpu _EJ0 callback
On Fri, Jan 13, 2012 at 12:11:30PM +0100, Vasilis Liaskovitis wrote:
>
> Signed-off-by: Vasilis Liaskovitis
The SeaBIOS change is okay with me, but the qemu/kvm change needs to
be accepted first.
[...]
> Method (CPEJ, 2, NotSerialized) {
> // _EJ0 method - eject callback
> +Store(ShiftLeft(1, Arg0), PRE)
> Sleep(200)
> }
Is the Sleep() still needed?
-Kevin
--
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: [PATCH 1/3][Seabios] Add bitmap for cpu _EJ0 callback
On Thu, Jan 19, 2012 at 03:02:30PM +0100, Vasilis Liaskovitis wrote:
> On Fri, Jan 13, 2012 at 07:27:01PM -0500, Kevin O'Connor wrote:
> >
> > [...]
> > > Method (CPEJ, 2, NotSerialized) {
> > > // _EJ0 method - eject callback
> > > +Store(ShiftLeft(1, Arg0), PRE)
> > > Sleep(200)
> > > }
> >
> I have another question here: the PCI _EJO callback seems to return 0x0, but
> the CPU _EJ0 doesn't return anything. THe ACPIspec4.0a draft section 6.3.3
> mentions that _EJx methods have no return value. Is the above difference
> intentional?
If the spec says it doesn't return anything, but the acpi code is,
it's probably just an error.
-Kevin
--
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: [PATCH RFC] seabios: add OSHP method stub
On Mon, Feb 13, 2012 at 11:33:08AM +0200, Michael S. Tsirkin wrote: > To allow guests to load the native SHPC driver > for a bridge, we must declare an OSHP method > for the appropriate device which lets the OS > take control of the SHPC. > As we don't access SHPC at the moment, we > don't need to do anything - just report success. The patch is fine with me, but since this is really qemu/kvm specific, please provide an ack from one of the qemu/kvm maintainers. -Kevin -- 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: [PATCH RFC] seabios: add OSHP method stub
On Tue, Feb 14, 2012 at 02:43:45AM +0200, Michael S. Tsirkin wrote: > On Mon, Feb 13, 2012 at 07:34:55PM -0500, Kevin O'Connor wrote: > > On Mon, Feb 13, 2012 at 11:33:08AM +0200, Michael S. Tsirkin wrote: > > > To allow guests to load the native SHPC driver > > > for a bridge, we must declare an OSHP method > > > for the appropriate device which lets the OS > > > take control of the SHPC. > > > As we don't access SHPC at the moment, we > > > don't need to do anything - just report success. > > > > The patch is fine with me, but since this is really qemu/kvm specific, > > please provide an ack from one of the qemu/kvm maintainers. > > > > -Kevin > > I expect no problem with this, > though I'm wondering what makes it qemu specific. Only kvm/qemu use the ACPI tables in seabios. In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking for an additional Ack. -Kevin -- 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: The way of mapping BIOS into the guest's address space
On Tue, Feb 14, 2012 at 04:13:42PM +0400, Cyrill Gorcunov wrote: > On Tue, Feb 14, 2012 at 01:10:59PM +0200, Pekka Enberg wrote: > > On Tue, Feb 14, 2012 at 1:03 PM, Yang Bai wrote: > > > Since on X86, bios is always at the end of the address space, so I > > > have some thought about how to implement the seabios support for kvm > > > tool. > > > > > > 1. using kvm__register_mem to map the end of address space to the > > > guest then copy the code of seabios to this mem region. Just emulating > > > the bios chip. > > I think this is what should be done. > > > > > > > 2. leave the bios code alone and don't touch the guest's address > > > space. If the guest accesses the address belonging to the bios, it > > > will be an IO request and we can emulate the IO access to the bios > > > chip. > > > > > > Any ideas about this? > > > > The latter solution doesn't make any sense to me. Cyrill, do we really > > need to put the BIOS at the end of the address space? Don't we have > > unused space below 1 MB? > > I don't remember for sure how SeaBIOS works actually. What I rememer > is that it aquires all hw environment might have. So without real look > into seabios code I fear I can't answer. But reserving end of 4G address > space for bios copy sounds reasonable if we going to behave as real > hardware. Maybe we could poke someone from KVM camp for a hint? SeaBIOS has two ways to be deployed - first is to copy the image to the top of the first 1MB (eg, 0xe-0xf) and jump to 0xf000:0xfff0 in 16bit mode. The second way is to use the SeaBIOS elf and deploy into memory (according to the elf memory map) and jump to SeaBIOS in 32bit mode (according to the elf entry point). SeaBIOS doesn't really need to be in the top 4G of ram. SeaBIOS does expect to have normal PC hardware devices (eg, a PIC), though many hardware devices can be compiled out via its kconfig interface. The more interesting challenge will likely be in communicating critical pieces of information (eg, total memory size) into SeaBIOS. The SeaBIOS mailing list (seab...@seabios.org) is probably a better location for technical seabios questions. -Kevin -- 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: [RFC PATCH 3/9][SeaBIOS] acpi: generate hotplug memory devices.
On Thu, Apr 19, 2012 at 04:08:41PM +0200, Vasilis Liaskovitis wrote:
> The memory device generation is guided by qemu paravirt info. Seabios
> first uses the info to setup SRAT entries for the hotplug-able memory slots.
> Afterwards, build_memssdt uses the created SRAT entries to generate
> appropriate memory device objects. One memory device (and corresponding SRAT
> entry) is generated for each hotplug-able qemu memslot. Currently no SSDT
> memory device is created for initial system memory (the method can be
> generalized to all memory though).
>
> Signed-off-by: Vasilis Liaskovitis
> ---
> src/acpi.c | 151
> ++--
> 1 files changed, 147 insertions(+), 4 deletions(-)
>
> diff --git a/src/acpi.c b/src/acpi.c
> index 30888b9..5580099 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -484,6 +484,131 @@ build_ssdt(void)
> return ssdt;
> }
>
> +static unsigned char ssdt_mem[] = {
> +0x5b,0x82,0x47,0x07,0x4d,0x50,0x41,0x41,
This patch looks like it uses the SSDT generation mechanism that was
present in SeaBIOS v1.6.3. Since then, however, the runtime AML code
generation has been improved to be more dynamic. Any runtime
generated AML code should be updated to use the newer mechanisms.
-Kevin
--
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: [PATCHv4 15/15] Pass boot device list to firmware.
On Sun, Nov 14, 2010 at 05:39:41PM +0200, Gleb Natapov wrote: > +/* > + * This function returns device list as an array in a below format: > + * +-+-+---+-+---+-- > + * | n | l1 | devpath1| l2 | devpath2 | ... > + * +-+-+---+-+---+-- > + * where: > + * n - a number of devise pathes (one byte) > + * l - length of following device path string (one byte) > + * devpath - non-null terminated string of length l representing > + * one device path > + */ Why not just return a newline separated list that is null terminated? -Kevin -- 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: [PATCHv4 15/15] Pass boot device list to firmware.
On Mon, Nov 15, 2010 at 09:40:08AM +0200, Gleb Natapov wrote: > On Sun, Nov 14, 2010 at 10:40:33PM -0500, Kevin O'Connor wrote: > > Why not just return a newline separated list that is null terminated? > > > Doing it like this will needlessly complicate firmware side. How do you > know how much memory to allocate before reading device list? My preference would be for the size to be exposed via the QEMU_CFG_FILE_DIR selector. (My preference would be for all objects in fw_cfg to have entries in QEMU_CFG_FILE_DIR describing their size in a reliable manner.) -Kevin -- 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: seabios 0.6.1 regression
On Mon, Nov 15, 2010 at 06:09:45PM +0200, Avi Kivity wrote: > On 11/15/2010 05:49 PM, Avi Kivity wrote: > >On 11/15/2010 05:41 PM, Avi Kivity wrote: > >> > >>I think it's a miscompile. > >> > >>out/code16.o: > >> 1a4: 3e ds > >> 1a5: 6c insb (%dx),%es:(%edi) > >> > >>Note no 66 prefix. > >> > > > >It isn't, that was random crap. All the insb() code is 32-bit. > > > > Rewriting it to use inb / stos works (jecxz ; insb; loop doesn't) so > it looks like a kernel bug in insb emulation. Ughh. I can revert that change on stable-0.6.1 if needed. It sounds like we really do want this on the main branch though for the speed benefit it provides. -Kevin -- 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: [PATCHv4 15/15] Pass boot device list to firmware.
On Mon, Nov 15, 2010 at 03:36:25PM +0200, Gleb Natapov wrote: > On Mon, Nov 15, 2010 at 08:26:35AM -0500, Kevin O'Connor wrote: > > On Mon, Nov 15, 2010 at 09:40:08AM +0200, Gleb Natapov wrote: > > > On Sun, Nov 14, 2010 at 10:40:33PM -0500, Kevin O'Connor wrote: > > > > Why not just return a newline separated list that is null terminated? > > > > > > > Doing it like this will needlessly complicate firmware side. How do you > > > know how much memory to allocate before reading device list? > > > > My preference would be for the size to be exposed via the > > QEMU_CFG_FILE_DIR selector. (My preference would be for all objects > > in fw_cfg to have entries in QEMU_CFG_FILE_DIR describing their size > > in a reliable manner.) > > > Will interface suggested by Blue will be good for you? The one with two > fw_cfg ids. BOOTINDEX_LEN for len and BOOTINDEX_DATA for device list. I I dislike how different fw_cfg objects pass the length in different ways (eg, QEMU_CFG_E820_TABLE passes length as first 4 bytes). This is a common problem - I'd prefer if we could adopt one uniform way of passing length. I think QEMU_CFG_FILE_DIR solves this problem well. I also have an ulterior motive here. If the boot order is exposed as a newline separated list via an entry in QEMU_CFG_FILE_DIR, then this becomes free for coreboot users as well. (On coreboot, the boot order could be placed in a "file" in flash with no change to the seabios code.) -Kevin -- 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: [PATCHv4 15/15] Pass boot device list to firmware.
On Tue, Nov 16, 2010 at 09:22:45AM +0200, Gleb Natapov wrote:
> On Mon, Nov 15, 2010 at 09:52:19PM -0500, Kevin O'Connor wrote:
> > I also have an ulterior motive here. If the boot order is exposed as
> > a newline separated list via an entry in QEMU_CFG_FILE_DIR, then this
> > becomes free for coreboot users as well. (On coreboot, the boot order
> > could be placed in a "file" in flash with no change to the seabios
> > code.)
> >
> You can define get_boot_order() function and implement it differently
> for qemu and coreboot. For coreboot it will be one linear. Just call
> cbfs_copyfile("bootorder"). BTW why newline separation is important?
Sure, but it'd be nice to just use romfile_copy("bootorder").
Using newline separated just makes it easier for users to vi and/or
cat the file.
-Kevin
--
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: [PATCHv6 00/16] boot order specification
Hi Gleb, On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote: > Anthony, Blue > > No comments on this patch series for almost a week. Can it be applied? My apologies - I haven't had time to review. > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote: > > I am using open firmware naming scheme to specify device path names. > > In this version: added SCSI bus support. Pass boot order list as file > > to firmware. > > > > Names look like this on pci machine: [...] > > /p...@i0cf8/u...@1,2/h...@1/netw...@0/ether...@0 > > /r...@genroms/linuxboot.bin What's the plan for handling optionroms (ie, BCVs and BEVs)? This is an area which is a bit tricky - mainly due to legacy BIOS crud. An option rom can register either a BEV (eg, gpxe on a network card), or it can register one or more BCVs (eg, a scsi card registering two drives). How do we say boot from the optionrom on the second nic card? If you have a scsi card, how do we communicate that its second drive should be the c: drive? The ugly thing about BCVs is that they are not necessarily registered in the rom for the device that controls it. So, if you have two of the same type of scsi card, each with two drives, it's possible for the optionrom to put all four drives in the rom of the first scsi card. > > Gleb Natapov (16): [...] > > Pass boot device list to firmware. It looks like you went with a newline separated list. Thanks. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote: > On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote: > > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote: > > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote: > > > > I am using open firmware naming scheme to specify device path names. > > > > In this version: added SCSI bus support. Pass boot order list as file > > > > to firmware. > > > > > > > > Names look like this on pci machine: > > [...] > > > > /p...@i0cf8/u...@1,2/h...@1/netw...@0/ether...@0 > > > > /r...@genroms/linuxboot.bin > > > > What's the plan for handling optionroms (ie, BCVs and BEVs)? This is > > an area which is a bit tricky - mainly due to legacy BIOS crud. > > > > An option rom can register either a BEV (eg, gpxe on a network card), > > or it can register one or more BCVs (eg, a scsi card registering two > > drives). How do we say boot from the optionrom on the second nic > > card? If you have a scsi card, how do we communicate that its second > > drive should be the c: drive? > > > BEV should be easy. When you register BEV found on pci card you search > for device path to that pci card to determine BEV's boot order. SeaBIOS has two separate optionrom passes - one to extract the roms from the cards and one to find BEVs and BCVs. In order to correlate a rom to a pci device SeaBIOS would have to keep track of each rom it deploys and then correlate it during the BEV/BCV scan. >BCV > should be the same, but since one PCI card may register several > BCVs the problem is more complex. Device path has not only path to > SCSI PCI card but to specific target,lun too. For instance this path > /p...@i0cf8/s...@3,2/d...@0,0 points to SCSI card in pci slot 3 function 2 > target 1 lun 1. The question is if BCV provides us with enough information > to know what target/lun it is going to boot. How will seabios even know it's a SCSI card? All seabios sees is a PCI device with a valid option rom bar. Further, I don't see how seabios will know which BCV is which lun. BTW, I assume you're suggesting that if a disk is found first in the list then seabios should make that drive the c: and make hard drive booting be the first thing attempted? (This is what the seabios boot menu does.) > > The ugly thing about BCVs is that they are not necessarily registered > > in the rom for the device that controls it. So, if you have two of > > the same type of scsi card, each with two drives, it's possible for > > the optionrom to put all four drives in the rom of the first scsi > > card. > > > That just broken optionrom. I can't see how we can solve this without > communicating with such optionrom and letting it know what device we > want to boot from. I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically states that optionroms can do this. I don't know how many roms actually do it. The BCV and BEVs have a "product name string" that could be used to identify which one to boot. Unfortunately, there isn't a good way for qemu to find these strings (though maybe it could just hard code them for roms it ships with). SeaBIOS does show them in the boot menu, so a user could manually copy them to a command line. >There can be also legacy optionrom that just hooks > into int19 during init and hijack booting process entirely. I think > those problems exist on real HW too. That's a separate problem which I wouldn't worry too much about. The only roms that I've seen do this today are roms we have the source for and can change. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote: > > On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote: > > > BEV should be easy. When you register BEV found on pci card you search > > > for device path to that pci card to determine BEV's boot order. > > > > SeaBIOS has two separate optionrom passes - one to extract the roms > > from the cards and one to find BEVs and BCVs. In order to correlate a > > rom to a pci device SeaBIOS would have to keep track of each rom it > > deploys and then correlate it during the BEV/BCV scan. > > > Yeah. I looked at the Seabios code. The simplest would be to change > device path to point to rom instead of pci device. So if there is device > path /p...@i0cf8/ether...@3 when rom is copied into the memory the path > is changed to be /r...@addr where addr is memory address where rom was > copied. Seabios would change its local copy of the path? [...] > > How will seabios even know it's a SCSI card? All seabios sees is a > > PCI device with a valid option rom bar. Further, I don't see how > > seabios will know which BCV is which lun. > > > Seabios knows that this is SCSI card from its device class. I assume "ethernet" would be from device class as well? This seems fragile - it would require seabios to keep a list of device classes to name mappings, and a user may not be able to boot from a device if seabios isn't programmed for it (eg, a passthrough device). > Unfortunately it looks like bcv does not provide enough info to know what > target it corresponds too. I can't think of enything smart we can do > here, so lets just treat all bcvs as same priority. There's the product name and there's the order it was registered in (ie, the third bcv on the rom). [...] > > > That just broken optionrom. I can't see how we can solve this without > > > communicating with such optionrom and letting it know what device we > > > want to boot from. > > > > I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically > > states that optionroms can do this. I don't know how many roms > > actually do it. > > > BSS tries to documents things post factum. I hope it doesn't encourage > this type of option roms. But how it works if we have two scsi cards > both have same option rom and each one of them tries to register bcv for > all scsi card it found. Won't we have two bcvs registered for each scsi > car then? First optionrom finds all devices for that type of scsi card. Second optionrom detects that its drives have already been probed and resizes itself to zero. > > The BCV and BEVs have a "product name string" that could be used to > > identify which one to boot. Unfortunately, there isn't a good way for > > qemu to find these strings (though maybe it could just hard code them > > for roms it ships with). SeaBIOS does show them in the boot menu, so > > a user could manually copy them to a command line. > > > Two disks can have same product name no? And qemu can't even know > product names for pass through devices. Also I wouldn't worry about > optioroms qemu ships. We can fix those. The product name is supposed to be unique. From the spec: The data within each header must be valid. Especially the `BCV' and `Pointer to Product Name String' fields. The BCV should point to a procedure that installs only that device into INT 13h services. It is strongly recommended that the Product Name String for each header uniquely identify the device to which that header belongs, so that when these strings are displayed to the user in a menu, the user can intelligently recognize and choose devices connected to that controller without having to open up the computer. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Sat, Nov 27, 2010 at 07:06:19PM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote: > > On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote: > > > Yeah. I looked at the Seabios code. The simplest would be to change > > > device path to point to rom instead of pci device. So if there is device > > > path /p...@i0cf8/ether...@3 when rom is copied into the memory the path > > > is changed to be /r...@addr where addr is memory address where rom was > > > copied. > > Seabios would change its local copy of the path? > Yes. Thinking about this further - since the optionrom must be 2k aligned there are only 96 spots a rom can be in. So, it should be simple to just have optionrom_setup() declare a "u16 romaddr_to_bdf[96]". > > > > How will seabios even know it's a SCSI card? All seabios sees is a > > > > PCI device with a valid option rom bar. Further, I don't see how > > > > seabios will know which BCV is which lun. > > > > > > > Seabios knows that this is SCSI card from its device class. > > > > This seems fragile - it would require seabios to keep a list of device > > classes to name mappings, and a user may not be able to boot from a > > device if seabios isn't programmed for it (eg, a passthrough device). > > > Seabios can ignore device name from device path since the same > information is present in pci config space of the device. So the device path > can be /p...@i0cf8/s...@4 or /p...@i0cf8/@4 Seabios can detect that device > is scsi just by looking at config space of pci device in slot 4 function 0. I don't think seabios should try to parse the path. Instead, I think seabios should build a name for each device it finds using the same algorithm that qemu uses and then just do a string compare to see if there is a match. Also, if qemu wants seabios to boot from a rom, I think it should tell seabios that - something like "/p...@i0cf8/r...@4.0/b...@0" to mean make the drive declared by the rom on pci device 4 function 0 in the first found bcv the c: drive. > For, scsi I think, proper solution would be to have Seabios support for > scsi controller emulated by qemu. This will make all devices bootable from > BCV known to Seabios and will not require option rom. The only problem > then will be with pass through devices, but since now only the whole > scsi controller can be passed through not individual targets qemu can > point device path only to the controller and not individual targets too. I'm okay with adding scsi support to seabios. However, the problem doesn't go away as network booting still requires a rom. > > > Unfortunately it looks like bcv does not provide enough info to know what > > > target it corresponds too. I can't think of enything smart we can do > > > here, so lets just treat all bcvs as same priority. > > > > There's the product name and there's the order it was registered in > > (ie, the third bcv on the rom). > Doesn't help much if we can't correlate bcv to device path. I'm confused by this. SeaBIOS can't boot the device in this situation - it can only run a rom. I think qemu should try to send info on which rom to run, not which device to boot. Each rom is uniquely identifiable by the pci device it came from (or fw_cfg slot), and each BCV can be identified by either its instance or its product name. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote: > > I don't think seabios should try to parse the path. Instead, I think > > seabios should build a name for each device it finds using the same > > algorithm that qemu uses and then just do a string compare to see if > > there is a match. > > > > Also, if qemu wants seabios to boot from a rom, I think it should tell > > seabios that - something like "/p...@i0cf8/r...@4.0/b...@0" to mean make > > the drive declared by the rom on pci device 4 function 0 in the first > > found bcv the c: drive. > > > Qemu does not know that Seabios needs optionrom to boot from a device. > It knows even less about bcvs in option rom. Qemu knows about device > itself, not how firmware boots from it. If the user wants to boot from a device and that device has an optionrom, then it's a safe bet that the optionrom is needed to boot from it. In any case, I'd rather have qemu know which devices seabios can boot then have seabios try to figure out what rom to run from a device path. > > > > There's the product name and there's the order it was registered in > > > > (ie, the third bcv on the rom). > > > Doesn't help much if we can't correlate bcv to device path. > > > > I'm confused by this. SeaBIOS can't boot the device in this situation > > - it can only run a rom. I think qemu should try to send info on > > which rom to run, not which device to boot. Each rom is uniquely > > identifiable by the pci device it came from (or fw_cfg slot), and each > > BCV can be identified by either its instance or its product name. > > > For Qemu those optionroms are just binary blobs. It doesn't know why they > are needed at all (there is no difference for qemu between vga rom and > e1000 rom). > > BTW are you actually aware of any option rom with multiple BCVs and, if > yes, how those BCVs differ? Multiple BCVs - yes. A SCSI card will define a BCV for each attached drive. I don't have a scsi card myself, but the support was added by a user who ran into the problem first hand. I don't know if there are SCSI card roms that will register all the drives on multiple cards in the first rom. I wouldn't be surprised if there are because of the scarcity of space in the 0xc-0xf space. (Having secondary optionroms resize themselves to zero would be a big savings.) -Kevin -- 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: [PATCHv6 00/16] boot order specification
Trimming CC list, adding seabios list. On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote: > > On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote: > > > Qemu does not know that Seabios needs optionrom to boot from a device. > > > It knows even less about bcvs in option rom. Qemu knows about device > > > itself, not how firmware boots from it. > > > > If the user wants to boot from a device and that device has an > > optionrom, then it's a safe bet that the optionrom is needed to boot > > from it. > > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can > natively boot from has optionrom. What Seabios will do in such situation > and how qemu can know it? Besides qemu support tries to be firmware > agnostic. In such a situation, under my proposal, users wouldn't be able to specify a default boot from their scsi drive until after qemu was also upgraded to know seabios could boot native scsi. (Or, they'd only be able to do it by adding in a command-line option.) > > In any case, I'd rather have qemu know which devices seabios can boot > > then have seabios try to figure out what rom to run from a device > > path. > You run all of them just like you do now. Information you get from qemu is > only used for sorting BCV/BEV entries. BCV/BEV that does not have > corespondent boot path in boot order list is put at the end. If qemu sends in "/p...@i0cf8/s...@3/d...@0,0" or "/p...@i0cf8/ether...@4/ethernet-...@0" it will expect seabios to boot from the appropriate device. In both cases, seabios would need to run a rom in order to fulfill that request. Trying to figure out which rom is quite painful. That's why I'd prefer to see qemu instead pass in something like "/p...@i0cf8/r...@3/b...@0" or "/p...@i0cf8/r...@4/bev". That is, if the machine needs to boot via a rom I'd prefer qemu state that explicitly. BTW, in the situation where seabios has native device support (eg, ATA), I don't have any concerns. (The names are a bit verbose, but that's not really an issue.) > > > BTW are you actually aware of any option rom with multiple BCVs and, if > > > yes, how those BCVs differ? > > > > Multiple BCVs - yes. A SCSI card will define a BCV for each attached > > drive. I don't have a scsi card myself, but the support was added by > > a user who ran into the problem first hand. > Optionrom is static. How number of BCVs can depend on number of attached > drives? Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the memory, and the optionrom can and will modify itself with additional PNP headers so that it can list multiple BCVs - one for each drive. In particular, gPXE uses self modification to relocate parts of itself into high ram. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote: > On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote: > > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote: > > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can > > > natively boot from has optionrom. What Seabios will do in such situation > > > and how qemu can know it? Besides qemu support tries to be firmware > > > agnostic. > > > > In such a situation, under my proposal, users wouldn't be able to > > specify a default boot from their scsi drive until after qemu was also > > upgraded to know seabios could boot native scsi. (Or, they'd only be > > able to do it by adding in a command-line option.) > > > If scsi card has optionrom with only one bcv then Seabios can determine > its boot order from device path, so why not provide user with this > option today? It's unclear to me how SeaBIOS is supposed to do that. >Besides qemu may be used to emulates sparc with openbios and > this combination may be able to boot from scsi device. Qemu is not just > x86 emulator running Seabios. If there is problem with scsi boot we let > management know, so it will not create unbootable configuration. Today it > is impossible to boot guest from scsi in qemu btw. Qemu can send in "/p...@i0cf8/s...@3/d...@0,0" - it's just unclear what seabios is supposed to do with it. (If "ignore it" is the answer, that's fine with me.) > > If qemu sends in "/p...@i0cf8/s...@3/d...@0,0" or > > "/p...@i0cf8/ether...@4/ethernet-...@0" it will expect seabios to boot > > from the appropriate device. In both cases, seabios would need to run > > a rom in order to fulfill that request. Trying to figure out which > > rom is quite painful. That's why I'd prefer to see qemu instead pass > > in something like "/p...@i0cf8/r...@3/b...@0" or "/p...@i0cf8/r...@4/bev". > > That is, if the machine needs to boot via a rom I'd prefer qemu state > > that explicitly. > It is painful in Seabios it is impossible in qemu at all. There is no > way for qemu to know about BCVs or BEVs in optionroms especially > considering that they are created at runtime like you say bellow. It's not impossible - qemu could code up rules for when to request a rom boot and when to request a native boot. That may seem ugly, but (as near as I can tell) it's basically what you've asked seabios to do. If nothing else, qemu has the option to let the user pass in an explicit request via the command-line. > > BTW, in the situation where seabios has native device support (eg, > > ATA), I don't have any concerns. (The names are a bit verbose, but > > that's not really an issue.) > This + network booting are the may use case really. And I do not see > what problem we have with BEV devices. "/p...@i0cf8/r...@4/bev" is not > much different from "/p...@i0cf8/ether...@4/ethernet-...@0" since there > can be only one bev per pci device. It is easy for Seabios to see that > to boot from pci device in slot 4 func 0 it has to execute BEV. I'm still stuck on how seabios is supposed to know it's an ethernet card. Sure, seabios could hardcode translations from classid to strings, but that seems fragile. What happens when the user wants to boot from myranet, or fiberchannel, or whatnot? Maybe we can compromise here - if the user selects booting from a device, and qemu sees there is a rom for that device, then qemu can specify two boot options: /p...@i0cf8/ether...@4/ethernet-...@0 /p...@i0cf8/r...@4 SeaBIOS will ignore the first entry, and act on the second entry. If at some later point seabios knows how to natively boot from the device (eg, scsi), then it will use the first entry and ignore the second. BTW, how are PCI locations specified in these paths? They should have a (bus, dev, fn) - your examples only seem to show dev. How are the other parts specified? -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote: > On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote: > > It's unclear to me how SeaBIOS is supposed to do that. > > > Suppose we have "/p...@i0cf8/s...@3/d...@0,0" with boot index 5 in > boot devices list and suppose pci device in slot 3 function 0 has > optionrom. When Seabios load the option rom from device to memory it looks > for string that matches "/p...@i0cf8/@3.*" if the string is found option > rom gets boot index from it. In our case "/p...@i0cf8/s...@3/d...@0,0" > will match and optionrom will get boot index 5. In practice Seabios will > know that device is SCSI by reading device class so it will be able > to construct string "/p...@i0cf8/s...@3" and use simple strstr to find > matching device path. I recognize that if we had a regex engine in seabios this would work, but I'm reluctant to add one. strstr doesn't work becuase "@3" could match some unrelated part of the path (eg, don't want to match "/p...@i0cf8/s...@1/d...@3,0") - so, what you seem to want is "/p...@i0cf8/[^/]...@3(/|$)". [...] > > I'm still stuck on how seabios is supposed to know it's an ethernet > > card. Sure, seabios could hardcode translations from classid to > > strings, but that seems fragile. What happens when the user wants to > > boot from myranet, or fiberchannel, or whatnot? > This is not fragile since class to name translation is defined > by the spec. But even that is not required if Seabios will be a > little bit smarter and will implement fuzzy matching. i.e do not > match "/p...@i0cf8/ether...@4/ethernet-...@0" exactly but match > "/p...@i0cf8/@4.*" instead. I think we're agreeing here that we don't want to put class to name translation in seabios. :-) > > Maybe we can compromise here - if the user selects booting from a > > device, and qemu sees there is a rom for that device, then qemu can > > specify two boot options: > > > > /p...@i0cf8/ether...@4/ethernet-...@0 > > /p...@i0cf8/r...@4 > > > This patch series implement device paths as defined by Openfirmware > spec. /p...@i0cf8/r...@4 sould be out of spec. But I do not see why Seabios > can't build later from the former. Also I do not see why it would be > needed at all. The name isn't important to me - call it something else if you want. It's value is that SeaBIOS doesn't then need to do fuzzy matching or parsing of the device names. That is, we turn the list from boot devices to boot methods which makes life easier for the firmware. > > SeaBIOS will ignore the first entry, and act on the second entry. If > > at some later point seabios knows how to natively boot from the device > > (eg, scsi), then it will use the first entry and ignore the second. > > > If you let go to the idea of exact matching of string built by qemu in > Seabios it will be easy to see that /p...@i0cf8/ether...@4/ethernet-...@0 > provides everything that Seabios needs to know and even more. If > you ignore all the noise it just says "boot from pci device slot 4 fn > 0". Seabios may have native support for the card in the slot or it can > use option rom on the card. Qemu does not care. I'm having a hard time letting go of string matching. I understand all the info is there if SeaBIOS parses the string. However, I think parsing out openbios device strings is overkill in an x86 bios that just wants to order the boot objects it knows about. Is there an issue with qemu generating two strings for devices with roms? > > BTW, how are PCI locations specified in these paths? They should have > > a (bus, dev, fn) - your examples only seem to show dev. How are the > > other parts specified? > > > Bus numbers are assigned by a guest. Qemu knows nothing about them, so > it specify device path by topology. If pci bridge is present device > path will look like this: > /p...@i0cf8/p...@2/ether...@4,1/ethernet-...@0. > This path point to device in slot 4 fn 1 sitting on pci-to-pci bridge > in slot 2 fn 0 of host pci controller. Same is true for usb bus. I understand - it makes sense. This does mean that seabios will need to track where each pci bus comes from. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote: > >>If scsi card has optionrom with only one bcv then Seabios can determine > >>its boot order from device path, so why not provide user with this > >>option today? > >It's unclear to me how SeaBIOS is supposed to do that. > Try to keep track of which bcv/bev belongs to which pci device? It > should surely work for devices supported by seabios natively. No issues for any device with native support. I'm okay with the proposed syntax. > SeaBIOS should also know which device's rom registered which entry. It doesn't today, but that shouldn't be an issue to add. > It might become tricky though in case there are multiple identical > devices are present, say two e1000 cards, where the first rom could > register entries for both cards ... Right - here's where things get complicated. > >Maybe we can compromise here - if the user selects booting from a > >device, and qemu sees there is a rom for that device, then qemu can > >specify two boot options: > > > >/p...@i0cf8/ether...@4/ethernet-...@0 > >/p...@i0cf8/r...@4 > > > >SeaBIOS will ignore the first entry, and act on the second entry. > > SeaBIOS should be able to operate just fine with the first entry. > "ether...@4" means "the nic at bus address 4". As this is a PCI bus > "4" is the pci address. So SeaBIOS would just look what entries it > has for "00:04.0", run the rom, and ignore the "/ethernet-...@0" > part as it can't handle it. Right - I'm not happy about trying to parse out openbios device descriptors though. The natural flow (as I see it) is for seabios to find all the boot methods in the system and then see which ones have been requested to be prioritized. Trying to do fuzzy matching of found device to requested device just seems like an unnecessary pain IMO. >When booting via rom it can either just pick > the first entry unconditionally (probably good enougth in 99% of the > cases) or do some guesswork based on the order the entries are > registered. I guess that's the crux of the matter - I'd rather not do guessing in the firmware. The emulator is in a much better position to do heuristics and guessing - if nothing else, the emulator can allow the user to pass it in on the command-line. > >BTW, how are PCI locations specified in these paths? They should have > >a (bus, dev, fn) - your examples only seem to show dev. How are the > >other parts specified? > > fn is optional for fn=0, IIRC the syntax is "$cl...@$dev,$fn". > > Bus is specified via location in the tree, i.e. you'll see the > bridge for the secondary pci bus in the path, like this: > > /p...@i0cf8/bri...@7/ether...@3/... > > (not sure it is actually named 'bridge' in the openfirmware specs though). Thanks. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote: > On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote: > > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote: > > > If you let go to the idea of exact matching of string built by qemu in > > > Seabios it will be easy to see that /p...@i0cf8/ether...@4/ethernet-...@0 > > > provides everything that Seabios needs to know and even more. If > > > you ignore all the noise it just says "boot from pci device slot 4 fn > > > 0". Seabios may have native support for the card in the slot or it can > > > use option rom on the card. Qemu does not care. > > > > I'm having a hard time letting go of string matching. I understand > > all the info is there if SeaBIOS parses the string. However, I think > > parsing out openbios device strings is overkill in an x86 bios that > > just wants to order the boot objects it knows about. > > > > Is there an issue with qemu generating two strings for devices with > > roms? > > > I just do not see how I can justify this addition to qemu maintainers > given that the parsing code below is very simple. It doesn't look correct to me - it doesn't handle the case where the PCI device is on a bridge. BTW, what's the plan for handling SCSI adapters? Lets say a user has a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3 bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from lun3. I understand this use case may not be important for qemu, but I'd like to use the same code on coreboot. Being able to boot from any drive is important - it doesn't have to autodetect, but it should be possible. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Wed, Dec 01, 2010 at 02:27:40PM +0200, Gleb Natapov wrote: > On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote: > > BTW, what's the plan for handling SCSI adapters? Lets say a user has > > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3 > > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from > > lun3. I understand this use case may not be important for qemu, but > > I'd like to use the same code on coreboot. Being able to boot from > > any drive is important - it doesn't have to autodetect, but it should > > be possible. > > > We can't. Option rom does not give us back enough information to do so. > Form device path we know exactly what id:lun boot should be done from, > but pnp_data does not have information to map BCV back to id:lun. I do > not see how coreboot can provide better information to Seabios then > qemu here. You're thinking in terms of which device to boot, which does make this difficult. However, it's equally valid to think in terms of which boot method to invoke, which makes this easy. We could tell the coreboot user to edit the "bootorder" file and add "/p...@i0cf8/r...@4" (second rom on 4th pci device - the exact syntax of the name is not important). >BTW to create proper EDD entry for SCSI boot device BIOS also > needs too map BCV to id:lun. How it can be done? It's the responsibility of the rom to build the EDD info. I don't know if all roms do this - I don't believe it's possible to get at the EDD info until after the drive has been mapped (ie, too late to use it for boot ordering). > SCSI _is_ important for qemu. Not HBA we have now, but something supported > by recent operation systems out of the box. When such HBA will be emulated > in qemu we will add native Seabios support for it. I understand. However, we'll still need to support arbitrary rom based BEVs and BCVs, so the use case is still important. -Kevin -- 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: [PATCHv6 00/16] boot order specification
On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote: > On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote: > > You're thinking in terms of which device to boot, which does make this > > difficult. However, it's equally valid to think in terms of which > > boot method to invoke, which makes this easy. > It is not. Because boot methods are enumerated by a guest at runtime. > Qemu knows absolutely nothing about them. I am thinking in terms of > devices because this is the only thing I have in qemu. As before, a safe heuristic would be to request a rom boot for any device with a pci rom that the user requests to boot from. Note, your original proposal included a boot method: /r...@genroms/linuxboot.bin I'm asking to extend this to be able to include roms on PCI devices. > > We could tell the coreboot user to edit the "bootorder" file and add > > "/p...@i0cf8/r...@4" (second rom on 4th pci device - the exact syntax > > of the name is not important). > > > But how user should knows that second rom (I think you mean "second BCV") > on pci device 4.0 will boot from the new scsi cdrom that he just connected? > How can he tell that it should put second BCV there and not third or fifth > without running Seabios first and looking at F12 menu? Exactly - look at the F12 menu. (Or, for bonus points, one could write a program that scans roms on the booted coreboot system, presents the user with a menu, and then writes the requested boot method to "bootorder".) Being able to specify which boot method is a requirement for me. It doesn't have to be pretty, but it does have to be possible. > > >BTW to create proper EDD entry for SCSI boot device BIOS also > > > needs too map BCV to id:lun. How it can be done? > > > > It's the responsibility of the rom to build the EDD info. I don't > > know if all roms do this - I don't believe it's possible to get at the > > EDD info until after the drive has been mapped (ie, too late to use it > > for boot ordering). > How can we get to EDD info after device is mapped? Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that the 0x13 irq and handle the request (or jump to the bios handler for drives it doesn't know about). >Can we use "disconnect vector" > to connect device temporarily get EDD and then disconnect? No. > > I understand. However, we'll still need to support arbitrary rom > > based BEVs and BCVs, so the use case is still important. > > > We can't do something that is impossible. You've used this word "impossible" a few times - I'm afraid I don't know what it means. >For coreboot Seabios should > implement what BBS spec says i.e enumerate all BCVs, present boot menu > to the user, record number of BCVs and user's choice on non-volatile > storage (CMOS). Bleh - there's no need for that. Much more reliable is to record the device path for builtin devices or the boot method (device path of rom, plus bev/bcv instance) for rom based boots. -Kevin -- 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: USB Passthrough 1.1 performance problem...
On Tue, Dec 14, 2010 at 12:02:03PM +0200, Avi Kivity wrote:
> That could certainly be optimized. If the BAR is all along in its
> page, both on guest and host (if not, we can migrate it, at least on
> the host), we can use the same offset within the page on the host as
> it appears on the guest, and assign the entire page.
>
> We should make sure SeaBIOS uses a minimum alignment of 4k for mmio BARs.
Shouldn't be too hard to do that.
-Kevin
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -10,6 +10,7 @@
#include "biosvar.h" // GET_EBDA
#include "pci_ids.h" // PCI_VENDOR_ID_INTEL
#include "pci_regs.h" // PCI_COMMAND
+#include "memmap.h" // PAGE_SIZE
#include "dev-i440fx.h"
#define PCI_ROM_SLOT 6
@@ -90,6 +91,8 @@ static int pci_bios_allocate_region(u16 bdf, int region_num)
type = "prefmem";
msg = "decrease BUILD_PCIMEM_SIZE and recompile. size %x";
} else {
+if (size < PAGE_SIZE)
+size = PAGE_SIZE;
r = &pci_bios_mem_region;
type = "mem";
msg = "increase BUILD_PCIMEM_SIZE and recompile.";
--
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: [SeaBIOS] Graphics card pass-through working with two pass pci-initialization
On Wed, Jun 01, 2011 at 04:40:15PM +0200, Rudolf Marek wrote: > >Having a brief look at the coreboot code it seems static stuff (compiled by > >iasl) and dynamic bits are combined into the final dsdt table, is that > >correct? > > Yes the dsdt is static, it has just external references to ssdt > which is dynamically generated using the acpigen. > > Acpigen can generate the packages, names and sometimes even bits of methods. That's interesting. SeaBIOS also has similar code - see acpi.c:build_ssdt(). -Kevin -- 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: [SeaBIOS] Graphics card pass-through working with two pass pci-initialization
On Wed, Jun 01, 2011 at 11:20:29PM +0900, Isaku Yamahata wrote:
> On Wed, Jun 01, 2011 at 09:30:12AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> >> 0xE000 is hard-coded in the DSDT for both piix and q35 as below.
> >> If the range is determined dynamically, the area also needs to be
> >> updated somehow dynamically.
> >>
> >> ...
> >> Name (_CRS, ResourceTemplate ()
> >> ...
> >> DWordMemory (ResourceProducer, PosDecode, MinFixed,
> >> MaxFixed, NonCacheable, ReadWrite,
> >> 0x, // Address Space Granularity
> >> 0xE000, // Address Range Minimum
> >> 0xFEBF, // Address Range Maximum
> >> 0x, // Address Translation Offset
> >> 0x1EC0, // Address Length
> >> ,, , AddressRangeMemory, TypeStatic)
> >
> > Uhm, indeed. I know next to nothing about ACPI though. Ideas anyone
> > how this could be done?
>
> Right now what I can think of is.
> It would be possible to know the offset in AmlCode[] by
> compiling dsl with -l option. The we can get the mix of source and
> resulted hex with offset like
It's easier then this - as Avi indicated, one can turn _CRS into a
method which returns the current info with the PCI size filled in at
runtime. Something like:
Method (_CRS, 0, NotSerialized) {
Name (TMP, ResourceTemplate ()
{
...
})
CreateDWordField (TMPM, 0x123, TMP)
Store (TMPM, PCIM)
Return (TMP)
}
This is already done for other devices - see \SB.LNKS._CRS. For this
to work, the new variable PCIM needs to be set to the size of the PCI
region, which can be populated in the SSDT when it is built by
SeaBIOS.
As Jan points out though, is a dynamic PCI region really needed?
Those that need a large PCI region are also likely to need a large
amount of memory. Maybe the space for PCI should just be increased.
-Kevin
--
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: [PATCH 0/2] Fix booting tcm_vhost + seabios
On Fri, Mar 15, 2013 at 09:45:14AM +0800, Asias He wrote:
> Asias He (2):
> virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
> virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
Thanks. I pushed these patches.
-Kevin
--
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: KVM call agenda for 2013-05-28
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote: > Juan is not available now, and Anthony asked for > agenda to be sent early. > So here comes: > > Agenda for the meeting Tue, May 28: > > - Generating acpi tables I didn't see any meeting notes, but I thought it would be worthwhile to summarize the call. This is from memory so correct me if I got anything wrong. Anthony believes that the generation of ACPI tables is the task of the firmware. Reasons cited include security implications of running more code in qemu vs the guest context, complexities in running iasl on big-endian machines, possible complexity of having to regenerate tables on a vm reboot, overall sloppiness of doing it in QEMU. Raised that QOM interface should be sufficient. Kevin believes that the bios table code should be moved up into QEMU. Reasons cited include the churn rate in SeaBIOS for this QEMU feature (15-20% of all SeaBIOS commits since integrating with QEMU have been for bios tables; 20% of SeaBIOS commits in last year), complexity of trying to pass all the content needed to generate the tables (eg, device details, power tree, irq routing), complexity of scheduling changes across different repos and synchronizing their rollout, complexity of implemeting the code in both OVMF and SeaBIOS. Kevin wasn't aware of a requirement to regenerate acpi tables on a vm reboot. There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS. The possibility was also raised of a "rom" that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses). Anthony requested that patches be made that generate the ACPI tables in QEMU for the upcoming hotplug work, so that they could be evaluated to see if they truly do need to live in QEMU or if the code could live in the firmware. There were no objections. -Kevin -- 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: [SeaBIOS] KVM call agenda for 2013-05-28
On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote: > Gerd Hoffmann writes: > > On 05/29/13 01:53, Kevin O'Connor wrote: > >> Raised > >> that QOM interface should be sufficient. > > > > Agree on this one. Ideally the acpi table generation code should be > > able to gather all information it needs from the qom tree, so it can be > > a standalone C file instead of being scattered over all qemu. > > Ack. So my basic argument is why not expose the QOM interfaces to > firmware and move the generation code there? I remain doubtful that QOM has all the info needed to generate the BIOS tables. Does QOM describe how the 5th pci device uses global interrupt 11 when using global interrupts, legacy interrupt 5 when not using global interrupts, and that the legacy interrupt can be changed by writing to the 0x60 address of the 1st pci device's config space? Does QOM state that the machine supports S3 sleep mode? Does QOM indicate that an IPMI device supports the 3rd version of the IPMI device specification? I don't see how exporting QOM to the firmware will help. I predict we would continue to see most of the BIOS tables hardcoded in the firmware and that all but the most minor changes to those tables would require synchronizing code patches to both QEMU and the firmware. I also suspect we would end up adding fields to QOM that only the BIOS tables cared about, and that ever increasing code would be needed in both QEMU and the firmware to juggle to/from QOM so that the BIOS tables could be created. -Kevin -- 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: KVM call agenda for 2013-05-28
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote: > There were discussions on potentially introducing a middle component > to generate the tables. Coreboot was raised as a possibility, and > David thought it would be okay to use coreboot for both OVMF and > SeaBIOS. The possibility was also raised of a "rom" that lives in the > qemu repo, is run in the guest, and generates the tables (which is > similar to the hvmloader approach that Xen uses). Given the objections to implementing ACPI directly in QEMU, one possible way forward would be to split the current SeaBIOS rom into two roms: "qvmloader" and "seabios". The "qvmloader" would do the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it. With both the hardware implementation and acpi descriptions for that hardware in the same source code repository, it would be possible to implement changes to both in a single patch series. The fwcfg entries used to pass data between qemu and qvmloader could also be changed in a single patch and thus those fwcfg entries would not need to be considered a stable interface. The qvmloader code also wouldn't need the 16bit handlers that seabios requires and thus wouldn't need the full complexity of the seabios build. Finally, it's possible that both ovmf and seabios could use a single qvmloader implementation. On the down side, reboots can be a bit goofy today in kvm, and that would need to be settled before something like qvmloader could be implemented. Also, it may be problematic to support passing of bios tables from qvmloader to seabios for guests with only 1 meg of ram. Thoughts? -Kevin -- 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: KVM call agenda for 2013-05-28
On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote: > Kevin O'Connor writes: > > Given the objections to implementing ACPI directly in QEMU, one > > possible way forward would be to split the current SeaBIOS rom into > > two roms: "qvmloader" and "seabios". The "qvmloader" would do the > > qemu specific platform init (pci init, smm init, mtrr init, bios > > tables) and then load and run the regular seabios rom. > What about a small change to the SeaBIOS build system to allow ACPI > table generation to be done via a "plugin". Using a runtime plugin (eg, "qplugin") would require a more complex handoff then qvmloader. With qplugin, seabios would need to know what memory qplugin is compiled to run in and make sure it didn't allocate anything there. Similarly, qplugin would need to not stomp on seabios while it runs, and it would need to coordinate with seabios where to place the final tables. With qvmloader, there is no need to coordinate memory addresses, so it can run anywhere, deploy the tables in their final location, and then launch seabios. > This could be as simple as moving acpi.c and *.dsl into the QEMU build > tree and then having a way to point the SeaBIOS makefiles to our copy of > it. I don't see how that would work. It would complicate the seabios build (as it would require a copy of qemu source to compile), and the resulting seabios binary would be strongly tied to the qemu version it was compiled with and vice-versa. This would break distro seabios rpms. It would also cause great pain when bisecting and would be confusing even during regular compile/debug cycles. Internal seabios calls (eg, memory allocations, pci config accesses) would need to be static interfaces, etc. -Kevin -- 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: [SeaBIOS] KVM call agenda for 2013-05-28
On Fri, May 31, 2013 at 10:13:34AM +0200, Peter Stuge wrote: > Kevin O'Connor wrote: > > one possible way forward would be to split the current SeaBIOS rom > > into two roms: "qvmloader" and "seabios". The "qvmloader" would do > > the qemu specific platform init (pci init, smm init, mtrr init, bios > > tables) and then load and run the regular seabios rom. > > qvmloader sounds a lot like coreboot. Agreed. I don't much like the qvmloader idea. I did want to open up discussion on the possibility, however. The only advantage it has over coreboot is that it could reasonably live in the qemu repo, and I do think that the hardware descriptions should like in the same code repo as the hardware implementation. -Kevin -- 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: [PATCH RFC] virtio-pci: new config layout: using memory BAR
I only recently saw this email.
On Thu, Jun 06, 2013 at 06:10:12PM +0300, Gleb Natapov wrote:
> On Thu, Jun 06, 2013 at 05:06:32PM +0200, Gerd Hoffmann wrote:
> > For seabios itself this isn't a big issue, see pci_{readl,writel} in
> > src/pci.c. When called in 16bit mode it goes into 32bit mode
> > temporarily, just for accessing the mmio register. ahci driver uses it,
> > xhci driver (wip atm) will use that too, and virtio-{blk,scsi} drivers
> > in seabios can do the same.
> >
> Isn't this approach broken? How can SeaBIOS be sure it restores real
> mode registers to exactly same state they were before entering 32bit
> mode?
You are correct - SeaBIOS can't fully restore the "hidden" segment
registers. So, in a way it is broken.
In practice, it seems to work on modern bootloaders (eg, ntldr, grub,
lilo). It definitely doesn't work with EMM386 (old DOS stuff), but
does seem to work okay with FreeDOS as long as one doesn't run EMM386.
The AHCI code uses this 32bit/16bit trampoline because it would not be
possible to support AHCI otherwise. I haven't seen any complaints of
failures with the AHCI code - probably because people using AHCI are
using modern guests.
I explored this a bit some time back and the only way I could think of
to reliably restore the 16bit registers would be via SMM.
Unfortunately, using SMM introduces a whole host of complexity and
problems.
-Kevin
--
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: [SeaBIOS] [PATCH v3] add acpi pmtimer support
On Wed, Sep 05, 2012 at 07:28:15AM +0200, Gerd Hoffmann wrote:
> This patch makes seabios use the acpi pmtimer instead of tsc for
> timekeeping. The pmtimer has a fixed frequency and doesn't need
> calibration, thus it doesn't suffer from calibration errors due to a
> loaded host machine.
>
> [ v3: mask port ioport read ]
[...]
> +static u64 pmtimer_get(void)
> +{
> +u16 ioport = GET_GLOBAL(pmtimer_ioport);
> +u32 wraps = GET_LOW(pmtimer_wraps);
> +u32 pmtimer = inl(ioport);
Mask still missing?
-Kevin
--
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: [PATCH 3/3] support readonly memory feature in qemu
On Mon, Sep 10, 2012 at 11:25:38AM +0200, Jan Kiszka wrote:
> On 2012-09-09 17:45, Avi Kivity wrote:
> > On 09/07/2012 11:50 AM, Jan Kiszka wrote:
> >>
> >>> +} else {
> >>> +cpu_physical_memory_rw(run->mmio.phys_addr,
> >>> + run->mmio.data,
> >>> + run->mmio.len,
> >>> + run->mmio.is_write);
> >>> +}
> >>> +
> >>> ret = 0;
> >>> break;
> >>> case KVM_EXIT_IRQ_WINDOW_OPEN:
> >>>
> >>
> >> Great to see this feature for KVM finally! I'm just afraid that this
> >> will finally break good old isapc - due to broken Seabios. KVM used to
> >> "unbreak" it as it didn't respect write protections. ;)
> >
> > Can you describe the breakage?
>
> Try "qemu -machine isapc [-enable-kvm]". Seabios is writing to some
> read-only marked area. Don't recall where precisely.
On boot, QEMU marks the memory at 0xc-0x10 as read-only.
SeaBIOS then makes the area read-write, performs its init, and then
makes portions of it read-only before launching the OS.
The registers SeaBIOS uses to make the memory read-write are on a PCI
device. On isapc, this device is not reachable, and thus SeaBIOS
can't make the memory writable.
The easiest way to fix this is to change QEMU to boot with the area
read-write. There's no real gain in booting with the memory read-only
as the first thing SeaBIOS does is make it read-write.
-Kevin
--
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: [PATCH 3/3] support readonly memory feature in qemu
On Tue, Sep 11, 2012 at 11:15:50AM -0500, Anthony Liguori wrote: > Jan Kiszka writes: > > On 2012-09-11 05:02, Kevin O'Connor wrote: > >> The easiest way to fix this is to change QEMU to boot with the area > >> read-write. There's no real gain in booting with the memory read-only > >> as the first thing SeaBIOS does is make it read-write. > > > > Considering SeaBIOS, that is true. If Seabios depends inherently on > > shadow ROMs and as we have no real chipset for isapc to control > > shadowing behavior, that will likely be the best option. Can have a > > look. > > I've never really understood this. > > Why do we need ISAPC? An ISA-only OS would still be okay on a system > with an i440fx and no PCI devices, no? > > I think that makes a lot more sense because then SeaBIOS doesn't have to > deal with the notion of ISAPC. Regardless of whether or not there is a need to support an isapc machine, I think it would still be preferable to boot with the 0xc-0x10 memory in read-write mode. The SeaBIOS code to make that memory read-write without being able to modify any of that ram is awkward. -Kevin -- 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: [PATCH] seabios/pci: enable 64 bit bar on seabios
On Fri, Nov 02, 2012 at 01:42:08PM +0800, Xudong Hao wrote: > 64 bit bar sizing and MMIO allocation. The 64 bit window is placed above high > memory, top down from the end of guest physical address space. Your patch seems to be against an old version of SeaBIOS. The latest SeaBIOS already supports 64bit pci bars. -Kevin -- 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: kvm smm mode support?
On Mon, Apr 28, 2014 at 03:49:31PM +0200, Gerd Hoffmann wrote: > On Sa, 2014-04-26 at 13:02 +0200, Paolo Bonzini wrote: > > Il 26/04/2014 11:40, Paolo Bonzini ha scritto: > > > Il 25/04/2014 09:39, Gerd Hoffmann ha scritto: > > >> Anyone has plans to add smm support to kvm? > > > > > > No plans, but it should be a Simple Matter Of Programming... > > > > Well, we need: > > > > - an extra ioctl to inject an SMI (can be modeled after KVM_NMI) > > > > - an extra user exit triggered when SMM is entered or left > > > > - an extra ioctl (or a GET/SET_ONE_REG implementation) to read/write > > whether we are in SMM, used to determine whether the #UD produced by RSM > > should be forwarded to the guest or trigger emulation. > > OVMF probably wants set aside some ram which can't be accessed by the > OS, for secure boot emulation which is actually secure. Guess we'll > just go map/unmap some slot in the smm enter/leave vmexits? Or there > are better ways to do it? Normally, the memory at 0xa-0xc is only mapped when in SMM. And, as I understand it, in a multi-cpu system only the core handling the SMI can access that ram. (All other cores would continue to access IO space at 0xa-0xc.) -Kevin -- 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] [PATCHv2] seabios: enable io/memory unconditionally
Hi Michael, On Thu, Oct 08, 2009 at 05:53:46PM +0200, Michael S. Tsirkin wrote: > VGA adapters need to claim memory and i/o > transactions even if they do not have any > i/o or memory bars. E.g. PCI spec, page 297, > gives an example of such a device: > > Programming interface b > VGA-compatible controller. Memory > addresses 0A h through 0B > h. I/O addresses 3B0h to 3BBh > and 3C0h to 3DFh and all aliases of > these addresses. > > While we could check for these devices and special-case them, it is > easier to fix this by enabling i/o and memory space unconditionally: > devices that do not support it will just ignore this setting. This doesn't sound correct to me - I would think the vga option rom should enable the memory and io bars. I don't have enough knowledge to say for sure though - can someone else with knowledge in this area confirm this approach? -Kevin -- 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: [PATCHv2] seabios: enable io/memory unconditionally
On Mon, Oct 12, 2009 at 11:59:29AM +0200, Michael S. Tsirkin wrote: > VGA adapters need to claim memory and i/o > transactions even if they do not have any > i/o or memory bars. E.g. PCI spec, page 297, > gives an example of such a device: I've modified your patch slightly (to use new pci_config_maskw helper) and have committed it. Thanks, -Kevin -- 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] Re: [PATCH 2/3] qemu: make cirrus init value pci spec compliant
On Mon, Oct 12, 2009 at 08:44:56AM -0500, Anthony Liguori wrote: > Gleb Natapov wrote >>> BTW, I don't think it's write-protected and it probably should be? >>> >>> >> AFAIR it is not writable on plain qemu. >> > > KVM wants it to be writable for the TPR optimization. Historically, it > was read-only in QEMU but it changed to read-write in order to fake > coreboot into thinking that the bios implemented PMM which it doesn't. During init, SeaBIOS will enable writes to all memory between 0xc-0x10 - shadowing the ram as needed. Just prior to starting the boot phase, SeaBIOS will make the bios f-segment and all option roms read only. (Note, this differs from bochs-bios which doesn't make optionroms writable - seabios makes them writable because some optionroms need it.) As an aside, it would be nice if qemu would just start off with this memory as read/writable, as the shadoing process is ugly, it's qemu specific, and it always ends up as read/writable anyway. I'm not sure where coreboot or PMM comes into this. SeaBIOS does implement the Post Memory Manager calls. -Kevin -- 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: About cpu_set, CPU hotplug and related subjects
On Mon, Apr 19, 2010 at 04:34:54PM -0300, Lucas Meneghel Rodrigues wrote: > After doing some reading it seems to me that the reason why that is not > happening is because SeaBIOS still doesn't have code to support CPU hot > plugging as BochsBIOS did. As I understand it, the hotplug support was only in the kvm copy of bochs bios. It also limited the number of cpus one could use (I think 16). The current smp support in SeaBIOS doesn't limit the number of cpus. So, there has been reluctance to just port the old kvm bios code forward. -Kevin -- 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: [PATCH] Support for booting from virtio disks
On Sun, May 09, 2010 at 06:23:49PM +0300, Gleb Natapov wrote: > This patch adds native support for booting from virtio disks to Seabios. Thanks Gleb - it looks good to me. One thing I noticed - the virtio-pci.c file is missing a license statement and virtio-ring.c states GPL instead of LGPL. -Kevin -- 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: [PATCHv3] Support for booting from virtio disks
On Mon, May 10, 2010 at 11:36:37AM +0300, Gleb Natapov wrote: > This patch adds native support for booting from virtio disks to Seabios. > > Signed-off-by: Gleb Natapov Thanks - commit 89acfa3f. The patch had some compile errors on gcc3.4 and gcc4.5 - I went ahead and committed an update to fix the errors (commit 7d09d0e3). -Kevin -- 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: [SeaBIOS] [PATCHv2] Support for booting from virtio disks
On Tue, May 11, 2010 at 10:04:25AM +0100, Stefan Hajnoczi wrote: > From what I can tell SeaBIOS is reading CMOS_BIOS_BOOTFLAG1 and > CMOS_BIOS_BOOTFLAG2 from non-volatile memory. The values index into > bev[], which contains IPL entries (the drives). > > Is the order of bev[] entries well-defined? Is there a way for QEMU > command-line to know that the first virtio-blk device corresponds to x > and the IDE CD-ROM corresponds to y? SeaBIOS arranges for bev[0] = floppy, bev[1] = hd, bev[2] = cdrom, and bev[3] to be the first network card - it does this so that the boot order can be read from qemu. However, it's a pain to force this order. -Kevin -- 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: [SeaBIOS] [PATCHv2] Support for booting from virtio disks
On Tue, May 11, 2010 at 03:47:40PM +0300, Gleb Natapov wrote: > On Tue, May 11, 2010 at 08:45:29AM -0400, Kevin O'Connor wrote: > > On Tue, May 11, 2010 at 10:04:25AM +0100, Stefan Hajnoczi wrote: > > > From what I can tell SeaBIOS is reading CMOS_BIOS_BOOTFLAG1 and > > > CMOS_BIOS_BOOTFLAG2 from non-volatile memory. The values index into > > > bev[], which contains IPL entries (the drives). > > > > > > Is the order of bev[] entries well-defined? Is there a way for QEMU > > > command-line to know that the first virtio-blk device corresponds to x > > > and the IDE CD-ROM corresponds to y? > > > > SeaBIOS arranges for bev[0] = floppy, bev[1] = hd, bev[2] = cdrom, and > > bev[3] to be the first network card - it does this so that the boot > > order can be read from qemu. However, it's a pain to force this > > order. > > > What if there are more then one disk? It's possible to boot from the A drive (floppy) or the C drive (hd). There's no standard way to boot from the D drive. So, when booting from the second hard drive, SeaBIOS arranges for that drive to be mapped as the C drive. The boot order (eg, floppy, hd, cdroms, network cards) is determined by the BEV (Boot Execution Vector) list. The harddrive registration order (eg, C, D, E) is determined by the BCV (Boot Connection Vector) list. When one selects a hard drive in SeaBIOS' boot menu, SeaBIOS actually does two things - it makes hd booting the first entry in the BEV list and it makes the selected hd the first entry in the BCV list. It's a mess - but that's what the BIOS Boot Specification (BBS) defines. Both option roms and bootloaders depend on this behavior. -Kevin -- 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: [PATCHv2] Support for booting from virtio disks
On Wed, May 12, 2010 at 10:22:59AM +0300, Avi Kivity wrote: > On 05/11/2010 03:31 PM, Gleb Natapov wrote: > >Real BIOS can do that because it enumerates all bootable devices, > >attach name for each one of them and then asks user to configure > >boot order using names it attached to devices. In our case we > >want to provide boot order on qemu command line before BIOS > >enumerated devices, so qemu should be able to pass enough information > >about boot device so that BIOS can uniquely identify it after it will > >discover all bootable devices. bus/device pair can be such thing. > > Having a BIOS menu is also useful, you don't have to drop to the > management tool, instead you do everything from the console. Having a "setup menu" is something real hardware could use as well. I don't think the setup menu should be in SeaBIOS - instead, SeaBIOS could launch another program (stored in flash or qemu_fw) dedicated to doing setup. > >>Alternatively we can seed the order from the command line (-boot > >>id1,id2,id3 where id* are some qdev property attached to disks, this > >>is more flexible than the current syntax I think). > >> > >The problem is how to communicate this order to Seabios. > > Topology (bus/device/lun). USB is a pain here. It's posible with BDF (Bus/Dev/Fn) and port number (which accounts for hubs having ports as well). -Kevin -- 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-KVM with 3x IDE HDD + CDROM not working
On Wed, May 12, 2010 at 03:19:26PM +0200, Peter Lieven wrote: > Hi Qemu/KVM Devel Team, > > if I create a VM with more than 2 harddisks and a CDROM Image and > want to boot from CDROM this is not working. > From my understanding at least 3 IDE Drives + 1 IDE CDROM should work. > > cmdline: > /usr/bin/qemu-kvm-0.12.4 -net none -drive > file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -drive > file=/dev/sdc,if=ide,boot=off,cache=none,aio=native -drive > file=/dev/sdd,if=ide,boot=off,cache=none,aio=native -m 256 -cpu > qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' > -monitor tcp:0:4001,server,nowait -vnc :1 -name 'ide-test' -boot > order=dc,menu=on -cdrom > /home/kvm/cdrom/root/KNOPPIX_V6.2.1CD-2010-01-31-DE.iso -k de > -pidfile /var/run/qemu/vm-153.pid -mem-path /hugepages > -mem-prealloc -rtc base=utc,clock=vm -no-kvm-irqchip -usb > -usbdevice tablet > > SEABIOS shows error: Could not read from CDROM (code 0001) Your third drive conflicts with the cdrom. Try adding ",index=3" to the definition of sdd. Qemu should probably handle this better, but the above works for me. -Kevin -- 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: [kvm] Re: [PATCH 0/5] bios: >4G updates
Hi, On Thu, Oct 02, 2008 at 03:33:58PM +0300, Avi Kivity wrote: > Alex Williamson wrote: >>> It works, so I pushed it out. Alex, can you rebase your bios patches >>> on top of current HEAD? >>> >> >> I updated and resent the first patch in the 4 patch follow-on to this >> one. The remaining 3 patches still apply cleanly. I think Sheng was >> going to send out a patch to better follow the SDM when changing the >> MTRRs, but the first 3 patches are independent of that. Thanks, >> >> > > Applied all, thanks. As an aside, is there any interest in using SeaBIOS with kvm? SeaBIOS is a port of bochs bios to gcc. I've been using SeaBIOS (along with coreboot) to boot and provide bios functions on real hardware. It works fine under qemu also. I looked at the changes that kvm has in its local bochs bios repo. Most of the code is the same, however I noticed a number of msr settings which I didn't fully understand. If there is interest, the source code repository can be pulled by running: git clone git://git.linuxtogo.org/home/seabios.git There is a git browser at: http://git.linuxtogo.org/?p=kevin/seabios.git;a=summary And some precompiled binaries at: http://linuxtogo.org/~kevin/SeaBIOS/ Thoughts? -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 0/5] bios: >4G updates
On Tue, Oct 14, 2008 at 05:29:12PM +0200, Avi Kivity wrote: > > >> As an aside, is there any interest in using SeaBIOS with kvm? > >> > >> > > There is a great interest. I just don't know time frame for this. Avi? > > > > I'd like the seabios repository to be a git submodule, so we don't have > to rewrite stuff. So I'll experiment a bit with git submodules and pull > it in soon. > > Kevin, will you accept qemu-specific and kvm-specific patches to > SeaBIOS? I'd like to avoid permanent deltas. Yes. There is already code specific to qemu and coreboot. I don't see any issues with having a CONFIG_KVM build option. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 0/5] bios: >4G updates
On Wed, Oct 15, 2008 at 07:46:49PM +0200, Avi Kivity wrote: > Kevin O'Connor wrote: >> There is already code specific to qemu and coreboot. I don't see any >> issues with having a CONFIG_KVM build option. > > Most kvm specific patches would actually be fairly generic features that > haven't been upstreamed yet. The only truly kvm specific patch would be > tpr patching, which qemu doesn't need. Yeah - most of the stuff that is wrapped in "#ifdef BX_QEMU" in bochs bios is not really qemu specific. In SeaBIOS, there is no longer a CONFIG_QEMU option - instead the code has been unified where possible and feature specific options were added where necessary (eg, CONFIG_UUID_BACKDOOR). Hopefully we can do the same for KVM stuff. However, it's okay if that's not practical. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Seabios - read e820 table from qemu_cfg
On Tue, Jan 26, 2010 at 10:52:12PM +0100, Jes Sorensen wrote:
> Read optional table of e820 entries from qemu_cfg
[...]
> --- seabios.orig/src/paravirt.c
> +++ seabios/src/paravirt.c
> @@ -132,6 +132,23 @@ u16 qemu_cfg_smbios_entries(void)
> return cnt;
> }
>
> +u32 qemu_cfg_e820_entries(void)
> +{
> +u32 cnt;
> +
> +if (!qemu_cfg_present)
> +return 0;
> +
> +qemu_cfg_read_entry(&cnt, QEMU_CFG_E820_TABLE, sizeof(cnt));
> +return cnt;
> +}
> +
> +void* qemu_cfg_e820_load_next(void *addr)
> +{
> +qemu_cfg_read(addr, sizeof(struct e820_entry));
> +return addr;
> +}
I think defining accessor functions for every piece of data passed
through qemu-cfg interface is going to get tiring. I'd prefer to
extend the existing qemu-cfg "file" interface for new content.
For example, add a helper with something like:
int qemu_cfg_get_file(const char *name, void *dest, int maxsize);
> -if (kvm_para_available())
> -// 4 pages before the bios, 3 pages for vmx tss pages, the
> -// other page for EPT real mode pagetable
> -add_e820(0xfffbc000, 4*4096, E820_RESERVED);
> +if (kvm_para_available()) {
> +u32 count;
> +
> +count = qemu_cfg_e820_entries();
> +if (count) {
> +struct e820_entry entry;
> +int i;
> +
> +for (i = 0; i < count; i++) {
> +qemu_cfg_e820_load_next(&entry);
> +add_e820(entry.address, entry.length, entry.type);
> +}
and then this becomes:
struct e820entry map[128];
int len = qemu_cfg_get_file("e820map", &map, sizeof(map));
if (len >= 0)
for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Re: [PATCH] Seabios - read e820 table from qemu_cfg
On Fri, Jan 29, 2010 at 10:03:55AM +0100, Jes Sorensen wrote: > On 01/28/10 05:39, Kevin O'Connor wrote: > >The advantage being that it should be possible to write one set of > >helper functions in both qemu and seabios that can then be used to > >pass arbitrary content. > > The only issue here is that I designed the Seabios portion to not rely > on the size of the struct, to avoid having to statically reserve it like > in your example. Having the qemu_cfg_get_file() function return a > pointer to a file descriptor and then have a qemu_cfg_read() helper that > takes the descriptor as it's first argument would avoid this problem. SeaBIOS already has a maximum size for the e820 map (32) - see CONFIG_MAX_E820. > >As a side note, it should probably do the e820 map check even for qemu > >users (ie, not just kvm). > > Ah I didn't realize Seabios would try to use the fw_cfg interface if it > wasn't running on top of QEMU. That would be good to do. Your patch only used it for kvm. SeaBIOS will use fw_cfg on both qemu and kvm. -Kevin -- 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: [PATCH] Seabios - read e820 table from qemu_cfg
On Mon, Feb 08, 2010 at 11:31:40AM +0100, Jes Sorensen wrote:
> On 01/28/10 05:39, Kevin O'Connor wrote:
> >As a side note, it should probably do the e820 map check even for qemu
> >users (ie, not just kvm).
>
> Hi Kevin,
>
> Here is an updated version of the patch which does the e820 read
> unconditionally of the return from kvm_para_available() so it should
> work for coreboot too.
>
> I haven't touched the file descriptor issue as I find it's a different
> discussion.
I'd prefer to use the "file" method - but I wont hold up your patch
for it. If the host part of your patch is committed to qemu, I'll
commit the SeaBIOS part.
[...]
> +struct e820_entry {
> +u64 address;
> +u64 length;
> +u32 type;
> +};
I find this struct to be easily confused with 'struct e820entry' in
memmap.h. Both code should use the same struct, or the new struct
should clearly indicate it's for qemu (eg, "qemu_e820_entry").
Thanks,
-Kevin
--
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: [PATCH 1/2] qemu-kvm: extboot: Keep variables in RAM
On Fri, Feb 19, 2010 at 11:37:04AM -0800, H. Peter Anvin wrote: > On 02/19/2010 10:17 AM, Jan Kiszka wrote: > >> > >> Stefan posted a virtio-blk driver for gPXE. I like this approach > >> because it's generally useful (gPXE can be used with any BIOS). > > > > Does it allow a unified boot device selection, one menu for them all, no > > more "boot=on" workarounds? > > > > Well, it hooks into BBS if the underlying BIOS supports it. Without BBS > there is no ability to have a unified boot device selection. SeaBIOS does support BBS (both BEVs and BCVs). Also, under qemu, SeaBIOS will run option roms with memory writable and then lock the memory after the POST phase (as is required by the spec). SeaBIOS also support PMM (both temporary allocations and the PCIv3 extensions for permanent memory). Finally, I plan to commit a series of patches to SeaBIOS which add support for booting from USB drives. I imagine adding virtio support to SeaBIOS would not be difficult if someone wishes to take that on. -Kevin -- 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: [PATCH 2/4] KVM: Rework VCPU state writeback API
On Thu, Mar 04, 2010 at 01:21:12AM -0300, Marcelo Tosatti wrote: > The regression seems to be caused by seabios commit d7e998f. Kevin, the > failure can be seen on the attached screenshot, which happens on the > first reboot of WinXP 32 installation (after copying files etc). Sorry - I also noticed a bug in that commit recently. I pushed the fix I had in my local tree. -Kevin -- 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: [PATCH 2/4] KVM: Rework VCPU state writeback API
On Thu, Mar 04, 2010 at 03:35:52PM -0300, Marcelo Tosatti wrote: > On Thu, Mar 04, 2010 at 12:58:58AM -0500, Kevin O'Connor wrote: > > On Thu, Mar 04, 2010 at 01:21:12AM -0300, Marcelo Tosatti wrote: > > > The regression seems to be caused by seabios commit d7e998f. Kevin, the > > > failure can be seen on the attached screenshot, which happens on the > > > first reboot of WinXP 32 installation (after copying files etc). > > > > Sorry - I also noticed a bug in that commit recently. I pushed the > > fix I had in my local tree. > > Thanks, it does fix the issue here. Anthony can you please update > seabios? Neither commit d7e998f nor the fix 8f469b96 are on the SeaBIOS stable branch. Is qemu ready to pull in bigger changes now? -Kevin -- 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: [PATCH 1/4] pci: expand tabs to spaces in pci_ids.h and pci_regs.h
On Sat, Aug 28, 2010 at 06:02:55PM +0300, Eduard - Gabriel Munteanu wrote: > The conversion was done using the GNU 'expand' tool (default settings) > to make it obey the SeaBIOS coding style. > > Signed-off-by: Eduard - Gabriel Munteanu Thanks Eduard. Patch 1 - I don't think we should reindent pci_ids.h - it's a copy from Linux - reindenting will make diff'ing it harder. Patch 2 & 3 - Can you get an acked'ed by from qemu/kvm developers? Patch 4 - I think this will have to wait until there is a plan for handling acpi tables. I'd like to tackle this post seabios v0.6.1. -Kevin -- 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: cpu hotplug
On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote: > Hi everyone, > > I'm currently looking into hotplugging CPUs. > This exclusively with linux-guests and linux-host. > I have found some (conflicting) information about this on the net. > > As far as I read: > * seabios doesn't support SMP (but why does the linux-guest show > multiple cpus?) > * there is no uniform way of informing the linux kernel that a cpu has > added (Found references to a unisys way of doing it though, which seems > to be still implemented) > * the kernel needs the acpi tables to determine how many cpus it has, > thus the support in the bios would involve an aml-compiler to > hot-compile new acpi tables. SeaBIOS version 0.6.1 has ACPI support for cpu-hotplug. It's been tested on Linux and Windows. Search the mail archive for "cpu hotplug" for the details. -Kevin -- 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: cpu hotplug
On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: > On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote: > > hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today) > > I get: [...] > > any ideas ? > > > Known problem in qemu. There was a patch for this, but qemu maintainers > think it is not good enough. Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for me. -Kevin -- 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: cpu hotplug
On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote: > On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote: > > On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: > > > Known problem in qemu. There was a patch for this, but qemu maintainers > > > think it is not good enough. > > Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for > > me. > hm... that's the version I am using und it does not work here ;( > the hotplug itself seems to work but they're reported as halted. > Could you confirm that the cpus in the monitor as reported by "info > cpus" are not reported as "(halted)" ? I sent my email before I saw that you and Gleb had continued the thread. It works in the sense that if I run two cpu hogs in a guest with one cpu I use only one host cpu used. When I turn on an additional guest cpu, I see two host cpus being used. But otherwise, "info cpus" does seem inaccurate. -Kevin -- 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: cpu hotplug
On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote: > halted state is not the way to check for whether cpu is online or > offline. cpu may be online but executing hlt instruction so > its state will be halted, but cpu itself is online. Actually with kvm > today you are not able to check that cpu is offline if it was ever > online. Query a guest for cpu status. In that regard, "info cpus" does seem to work - as it only shows me the cpus that have ever been online. Ejecting a cpu in the guest does not remove it from "info cpus", but then, I don't think kvm does remove it from being available after an eject. -Kevin -- 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: cpu hotplug
On Sun, Sep 19, 2010 at 04:07:50PM +0200, Conrad Wood wrote: > 1) Thanks for clarifying "online" vs "halted" - that makes sense and is > probably part of what confused me. I need to get the "online/offline" > status of cpus, not if they are halted or not. I understand this is > currently not possible with kvm. As I have no direct control over the > guest OS, I do however need a solution on the host. Any clues how this > could be implemented would be much appreciated. > This is important to me. I thought I read somewhere that kvm does not currently support taking a cpu offline - the guest can only voluntarily stop using a cpu. (Gleb would know better, but I think he was trying to say the same thing.) > 2) In my case, the cpus are ALWAYS reported as halted, regardless of the > current state in the guest. > After the guest booted, The "cpu infos" displays precisely the amount of > cpus as initially set by the -smp parameter of kvm. (as halted). > any additional cpus added later will be displayed, also as halted - > again regardless whether or not the guest switches or had switched them > to online. It is reported as "halted" even whilst the guest is running a > cpu-hogger which would stop the cpu from halting. > I don't mind so much about this cosmetic display problem ;) I suppose one could check the host cpu usage of the thread reported in "info cpus". -Kevin -- 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: cpu hotplug
On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote: > On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote: > > > > > > However after step 7 the guest can turn the cpu online again by issuing > > > > echo 1 >/sys/devices/.../cpuX/online > > > There will be no /sys/devices/.../cpuX/online in guest after step 7. > > > > Well then at least in my version there's a bug, because it still is > > there and never goes away. (kvm 0.12.5) > > And changing it to online works as well. > Can you provide exact steps you are using? After doing cpu_set x offline > cpu x should disappear from a guest. Otherwise cpu eject didn't work. I'm confused. The "cpu_set x offline" doesn't appear to do anything for me. It does not disable the cpu, nor does it inform the guest to disable the cpu. The only way I'm able to remove a cpu is to run in the guest: echo 1 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:xx/eject which (as far as I know) is purely a voluntary guest disable of the cpu. It doesn't (as far as I know) even tell kvm that it is no longer using the cpu. (The acpi cpu eject method in seabios just issues a sleep(200) call.) -Kevin -- 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: cpu hotplug
On Sun, Sep 19, 2010 at 06:24:33PM +0200, Conrad Wood wrote:
>
> a script with my exact steps is below. Result is reproducible.
>
[...]
> echo "Ejecting CPU #4"
> echo "cpu_set 4 offline" | nc ${MONITORHOST} ${MONITORPORT} >/dev/null
>
> printInfo
>
> echo "Setting all available cpus to online..."
> ssh -lroot ${VM} "find /sys/devices/system/cpu/ -type f -path
> '*/cpu?/online' -exec bash -c \"echo 1 >{}\" \;"
It's not clear if you can trust your guests or not. If you can trust
the guest OS, it should be safe to run:
echo 1 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:xx/eject
in the guest. A normal linux guest wont reactivate the cpu after
that.
-Kevin
--
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: cpu hotplug
On Sun, Sep 19, 2010 at 06:12:14PM +0200, Gleb Natapov wrote: > On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote: > > I'm confused. The "cpu_set x offline" doesn't appear to do anything > > for me. It does not disable the cpu, nor does it inform the guest to > > disable the cpu. [...] > Then cpu eject method in seabios has a bug. When "cpu_set x offline" is > called qemu sets status bit in gpe and injects ACPI interrupt. ACPI > should do Notify() on cpu object when it happens. I was wrong. The "cpu_set x offline" does send an event to the guest OS. SeaBIOS even forwards the event along - as far as I can tell a Notify(CPxx, 3) event is generated by SeaBIOS. My Windows 7 ultimate beta seems to receive the event okay (it pops up a dialog box which says you can't unplug cpus). Unfortunately, my test linux guest OS (FC13) doesn't seem to do anything with the unplug Notify event. I've tried with the original FC13 and with a fully updated version - no luck. So, I'm guessing this has something to do with the guest OS. -Kevin -- 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: cpu hotplug
On Mon, Sep 20, 2010 at 08:50:17AM +0200, Gleb Natapov wrote: > On Sun, Sep 19, 2010 at 06:03:31PM -0400, Kevin O'Connor wrote: > > I was wrong. The "cpu_set x offline" does send an event to the guest > > OS. SeaBIOS even forwards the event along - as far as I can tell a > > Notify(CPxx, 3) event is generated by SeaBIOS. > > > > My Windows 7 ultimate beta seems to receive the event okay (it pops up > > a dialog box which says you can't unplug cpus). > > > It may react to Eject() method. The eject method is called by the OS to notify the host. Right now SeaBIOS's eject method doesn't do anything. > > Unfortunately, my test linux guest OS (FC13) doesn't seem to do > > anything with the unplug Notify event. I've tried with the original > > FC13 and with a fully updated version - no luck. > > > > So, I'm guessing this has something to do with the guest OS. > > > Can you verify that _STA() return zero after cpu unplug? I've verified that. I've also verified that Linux doesn't call the _STA method after Notify(CPxx, 3). It does call _STA on startup and after a Notify(CPxx, 1) event. So, the Linux kernel in my FC13 guest just seems to be ignoring Notify(3) events. (According to ACPI spec, the guest should shutdown the cpu and then call the eject method.) -Kevin -- 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: [PATCH] support piix PAM registers in KVM
On Tue, Sep 21, 2010 at 04:06:01PM -0300, Marcelo Tosatti wrote: > On Tue, Sep 21, 2010 at 02:31:42PM +0200, Gleb Natapov wrote: > > Without this BIOS fails to remap 0xf memory from ROM to RAM so writes > > to F-segment modify ROM content instead of memory copy. Since QEMU does > > not reloads ROMs during reset on next boot modified copy of BIOS is used. > > > > Signed-off-by: Gleb Natapov > Applied, thanks. Thanks. I've committed the seabios relocation patches that depended on this fix. -Kevin -- 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: system_powerdown not working for qemu-kvm 0.12.4?
On Tue, Oct 12, 2010 at 08:49:58AM +0200, Avi Kivity wrote:
> On 10/11/2010 07:53 PM, Ruben Kerkhof wrote:
> >5c99b6c984682ddb1d4543a7e27a1f4ca633e6a6 is the first bad commit
> >commit 5c99b6c984682ddb1d4543a7e27a1f4ca633e6a6
> >Author: Kevin O'Connor
> Gleb, Kevin, any ideas?
>
> (summary: qemu-kvm doesn't acpi shutdown freebsd 8.1 with this
> commit; qemu.git does. May be due to interrupt polarity which kvm
> implements but qemu does not)
The only thing in commit 5c99b6c9 that could cause an issue is that it
has the compiled acpi changes actually made in commit 29f4b912, but I
don't see how that would be a problem to reboots:
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index cee038a..2bede25 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -58,7 +58,10 @@ DefinitionBlock (
#define prt_slot2(nr) prt_slot(nr, LNKB, LNKC, LNKD, LNKA)
#define prt_slot3(nr) prt_slot(nr, LNKC, LNKD, LNKA, LNKB)
prt_slot0(0x),
- prt_slot1(0x0001),
+ Package() { 0x0001, 0, 0, 9 },
+ Package() { 0x0001, 1, LNKB, 0 },
+ Package() { 0x0001, 2, LNKC, 0 },
+ Package() { 0x0001, 3, LNKD, 0 },
prt_slot2(0x0002),
prt_slot3(0x0003),
prt_slot0(0x0004),
Can you confirm that commit 4c94b7ea works reliably while commit
5c99b6c9 does not?
-Kevin
--
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: [SeaBIOS] [PATCH] mark irq9 active high in DSDT
On Thu, Oct 21, 2010 at 12:07:17PM +0200, Avi Kivity wrote: > How do we manage the stable series wrt this issue? > > qemu-kvm-0.12.5 has a regression within the stable series that this > patch fixes. qemu 0.12.5 does not, but only because it does not > emulate polarity in the I/O APIC correctly. > > There are several paths we could take: > > - do nothing, bug is fixed in mainline > - release a seabios 0.x.1 for qemu 0.13.1 with this patch > - same, plus seabios 0.y.1 for qemu 0.12.6 with this patch > - skip qemu (which is not truly affected), patch qemu-kvm's copy of > seabios for both 0.12.z and 0.13.z > > The third option is the most "correct" from a release engineering > point of view, but involves more work for everyone. I'm okay with making tags and branches of seabios for bug fixes. So far qemu/kvm has just grabbed various builds of seabios - is it worthwhile to branch off of the seabios-0.6.1 version - which would mean qemu/kvm would pull in additional changes beyond the bug fix above? -Kevin -- 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: [PATCHv2 0/8 RFC] boot order specification
On Sun, Oct 31, 2010 at 01:40:01PM +0200, Gleb Natapov wrote: > This is current sate of the patch series for people to comment on. > I tried to use open firmware naming scheme to specify device path names. > > The patch series produce names like these: > for pci machine: > /p...@i0cf8/pci-isa-bri...@1/f...@03f1/flo...@0 > /p...@i0cf8/pci-isa-bri...@1/f...@03f1/flo...@1 > /p...@i0cf8/a...@1,1/ata-d...@1:0 > /p...@i0cf8/a...@1,1/ata-d...@1:1 > /p...@i0cf8/virtio-...@3/virtio-d...@0 > /p...@i0cf8/ether...@4/ethernet-...@0 > /p...@i0cf8/ether...@5/ethernet-...@0 > > for isa machine: > adding '/isa/f...@03f1/flo...@0' at index 2 > adding '/isa/f...@03f1/flo...@1' at index 1 > adding '/isa/a...@0170/ata-d...@0:0' at index 0 > adding '/isa/a...@0170/ata-d...@0:1' at index 3 Hi Gleb, How will USB drives be identified? I'm not sure how SeaBIOS will be able to line up something like "/p...@i0cf8/ether...@4/ethernet-...@0" to an optionrom BEV. Also, if there is an optionrom with BCVs (eg, a scsi card), I'm not sure how that would that would be identified. -Kevin -- 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: [SeaBIOS] [PATCH] mark irq9 active high in DSDT
On Wed, Oct 27, 2010 at 03:27:58PM +0200, Avi Kivity wrote: > On the last kvm conf call Anthony said that he'll be happy to > include an updated seabios with qemu 0.13.1, so a new release would > be appreciated. I branched and tagged "rel-0.6.1.1". It only has 6d5a2172 cherry-picked into it. -Kevin -- 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
