Re: [RFC] kvmtool: add support for modern virtio-pci

[Gerd Hoffmann]

  Hi,

> That was indeed the ISR field. Fixing that makes seabios reach the same point 
> as
> legacy virtio before failing.
> 
> I don't see the original correspondence about seabios failures you've 
> reported, if
> you want to forward them over we can look at it further.

It was a few months back, when I posted the seabios patches for kvmtool
to both seabios and kvm lists.

Issue #1 is that kvmtool adds a bunch of kernel command line options,
not only for stuff like rootfs configuration, but also to force specific
things the kernel fails to autodetect (or to speedup boot by
shortcutting hardware probing).  Among them is "pci=conf1", without that
the kernel doesn't find a pci bus and therefore also doesn't find the
virtio-{blk,net} devices.

So, when booting with seabios and let grub or another boot loader load
the kernel from the guest disk image those kernel arguments are not
there.  Of course you can boot the image with qemu, add "pci=conf1" to
grub.cfg (maybe others are required too, don't remember exactly), then
try again with kvmtool.  That gets the boot one step further and leads
to ...

Issue #2: virtio kernel drivers fail initialize the virtio devices.
I suspect virtio device reset is not implemented properly and because of
that the state of the device as left by seabios confuses the kernel
driver.  Didn't check that in detail though.

cheers,
  Gerd


--
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] kvmtool: add support for modern virtio-pci

[Gerd Hoffmann]

  Hi,

> Thanks for testing! I didn't even thing about seabios as a testing target.

Not surprising, support isn't upstream, ran into a bunch of issues[1][2]
last time I tried to combine the two, ran into some issues and nobody
seemed to care, so the seabios patches where just sitting in a branch in
my repo ...

> $ cat .config | grep 'KVMTOOL\|DEBUG'
> CONFIG_KVMTOOL=y
> CONFIG_DEBUG_LEVEL=9

Hmm, 'CONFIG_KVMTOOL=y > .config; make olddefconfig' should give you a
working configuration.

Setting 'CONFIG_DEBUG_LEVEL=9' is useful for trouble-shooting as it
makes the virtio drivers more verbose, but not mandatory to have.

Serial line support is needed to get output:

CONFIG_DEBUG_SERIAL=y
CONFIG_DEBUG_SERIAL_PORT=0x3f8

Also I think rom size must be 128k b/c kvmtool expects it to be that
way:

CONFIG_ROM_SIZE=128

But those are the defaults, and after "make olddefconfig" you should
already have them ...

cheers,
  Gerd

[1] kernel doesn't find pci (can be worked around by tweaking kernel
command line in boot loader config).
[2] kernel virtio drivers fail to initialize (probably device reset
not working properly).


--
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] kvmtool: add support for modern virtio-pci

[Gerd Hoffmann]

On Mi, 2015-11-18 at 00:11 -0500, Sasha Levin wrote:
> This is a first go at adding support for the modern (based on the 1.0 virtio
> spec) virtio-pci implementation.

> To sum it up: this is a lightly tested version for feedback about the design
> and to weed out major bugs people notice. Feedback is very welcome!

/me goes undust the kvmtool patches for seabios.

(see https://www.kraxel.org/cgit/seabios/commit/?h=kvmtool,
build with CONFIG_KVMTOOL=y + CONFIG_DEBUG_LEVEL=9)

nilsson kraxel ~# ~kraxel/projects/kvmtool/lkvm run --name seabios
--firmware /home/kraxel/projects/seabios/out-bios-kvmtool/bios.bin
--disk /vmdisk/cloud/persistent/Fedora-Cloud-Base-22-20150521.x86_64.raw
  # lkvm run -k /boot/vmlinuz-3.10.0-324.el7.x86_64 -m 448 -c 4 --name
seabios
Changing serial settings was 0/0 now 3/0
SeaBIOS (version rel-1.9.0-7-g532b527)
BUILD: gcc: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4) binutils: version
2.23.52.0.1-55.el7 20130226
kvmtool: probed 448 MB RAM.
Add to e820 map:  1c00 1
malloc preinit
Add to e820 map: 000a 0005 -1
Add to e820 map: 000f 0001 2
Add to e820 map: 1bfc 0004 2
phys_alloc zone=0x000f78e8 size=14464 align=10 ret=1bfbc6f0
(detail=0x1bfbc6c0)
Relocating init from 0x000f40a0 to 0x1bfbc6f0 (size 14464)
malloc init
init ivt
init bda
Add to e820 map: 0009fc00 0400 2
init bios32
init PNPBIOS table
init keyboard
init mouse
init pic
math cp init
PCI probe
phys_alloc zone=0x1bfbff38 size=32 align=10 ret=1bfbc640
(detail=0x1bfbc610)
PCI device 00:00.0 (vd=1af4:1000 c=0200)
phys_alloc zone=0x1bfbff38 size=32 align=10 ret=1bfbc5f0
(detail=0x1bfbc5c0)
PCI device 00:01.0 (vd=1af4:1001 c=0180)
Found 2 PCI devices (max PCI bus is 00)
tsc calibrate start=71959316 end=71968721 diff=9405
CPU Mhz=5
init timer
init lpt
Found 2 lpt ports
init serial
Found 4 serial ports
init virtio-blk
found virtio-blk at 0:1
phys_alloc zone=0x1bfbff40 size=80 align=10 ret=f78d0
(detail=0x1bfbc590)
pci dev 0:1 virtio cap at 0x4c type 1 bar 0 at 0xd2000800 off +0x
[mmio]
pci dev 0:1 virtio cap at 0x5c type 2 bar 0 at 0xd2000800 off +0x0080
[mmio]
pci dev 0:1 virtio cap at 0x70 type 3 bar 0 at 0xd2000800 off +0x0100
[mmio]
pci dev 0:1 virtio cap at 0x80 type 4 bar 0 at 0xd2000800 off +0x0180
[mmio]
pci dev 0:1 using modern (1.0) virtio mode
vp write  d2000814 (1) <- 0x0
Segmentation fault

With '--virtio-legacy' added seabios manages to load the kernel from
disk.

cheers,
  Gerd


--
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] kvmtool: add support for modern virtio-pci

[Gerd Hoffmann]

On Mi, 2015-11-18 at 23:01 -0500, Sasha Levin wrote:
> On 11/18/2015 11:00 PM, Sasha Levin wrote:
> > Anyways, I debugged it for a bit a found that seabios attempts to write to
> > the notification BAR, I look further tomorrow to narrow it down and fix it.
> 
> Err, *read*, obviously.
> 
> I've never implemented that because the kernel doesn't try to do that (it 
> doesn't
> make much sense, I think...).

It doesn't make sense indeed (kvmtool still shouldn't segfault though),
and on a quick look I can't spot a place in seabios doing that ...

It's reading ISR, as part of device reset, to make sure any pending
interrupts are cleared.

cheers,
  Gerd


--
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: just an observation about USB

[Gerd Hoffmann]

On Fr, 2015-10-16 at 11:48 -0400, Eric S. Johansson wrote:
> 
> On 10/16/2015 07:55 AM, Stefan Hajnoczi wrote:
> > QEMU can emulate PCI soundcards, including the Intel HD Audio codec 
> > cards (-device intel-hda or -soundhw hda might do the trick). Low 
> > latency and power consumption are usually at odds with each other. 
> > That's because real-time audio requires small buffers many times per 
> > second, so lots of interrupts and power consumption. Anyway, PCI 
> > should be an improvement from USB audio. Stefan 
> 
> I set it up with ich9.  I switched the default audio to my headset. I 
> hear the windows startup sound in the headset. Dragon reports that the 
> mic is not plugged in.  I can see the audio level move in the sound 
> settings so I know the host is hearing the audio
> 
> what should I look at next?

Try '-device intel-hda -device hda-micro' (instead of -device intel-hda
-device hda-duplex', or '-soundhw hda' which is a shortcut for the
latter).

'hda-duplex' presents a codec with line-in and line-out to the guest.
'hda-micro' presents a codec with microphone and speaker to the guest.
Other than having in and out tagged differently the codecs are
identical.  But especially declaring the input being a mic seems to be
needed to make some picky windows software happy.

cheers,
  Gerd


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH 1/2] target-i386: disable LINT0 after reset

[Gerd Hoffmann]

On Mi, 2015-09-16 at 07:23 +0200, Jan Kiszka wrote:
> On 2015-09-15 23:19, Alex Williamson wrote:
> > On Mon, 2015-04-13 at 02:32 +0300, Nadav Amit wrote:
> >> Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long 
> >> gone
> >> and therefore this hack is no longer needed.  Since it violates the
> >> specifications, it is removed.
> >>
> >> Signed-off-by: Nadav Amit 
> >> ---
> >>  hw/intc/apic_common.c | 9 -
> >>  1 file changed, 9 deletions(-)
> > 
> > Please see bug: https://bugs.launchpad.net/qemu/+bug/1488363
> > 
> > Is this bug perhaps not as long gone as we thought, or is there
> > something else going on here?  Thanks,
> 
> I would say, someone needs to check if the SeaBIOS line that is supposed
> to enable LINT0 is actually executed on one of the broken systems and,
> if not, why not.

There is only one reason (beside miscompiling seabios with
CONFIG_QEMU=n) why seabios would skip acpi initialization, and that is
apic not being present according to cpuid:

cpuid(1, , , , _features);
if (eax < 1 || !(cpuid_features & CPUID_APIC)) {
// No apic - only the main cpu is present.

https://www.kraxel.org/cgit/seabios/tree/src/fw/smp.c#n79

cheers,
  Gerd

PS: coreboot tripped over this too, fixed just a few days ago.

--
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: virtio-serial: Add multiple times opening support to virtserialport(port)

[Gerd Hoffmann]

  Hi,

 AndroidPipe is a communication channel between the guest system and
 the emulator itself. Guest side device node can be opened by multi
 processes at the same time with different service name. It has a
 de-multiplexer on the QEMU side to figure out which service the guest
 actually wanted, so the first write after opening device node is the
 service name guest wanted, after QEMU backend receive this service
 name, create a corresponding communication channel, initialize related
 component, such as file descriptor which connect to the host socket
 serve. So each opening in guest will create a separated communication
 channel.
 
 We can create a separate device for each service type, however some
 services, such as the OpenGL emulation, need to have multiple open
 channels at a time. This is currently not possible using the
 virtserialport which can only be opened once.

vsock probably works better then:

http://events.linuxfoundation.org/sites/events/files/slides/stefanha-kvm-forum-2015.pdf

Also: for opengl you might want check out virtio-gpu (assuming you can
build mesa for android).

https://www.kraxel.org/slides/qemu-opengl/

cheers,
  Gerd


--
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

[PATCH 3/7] kvmtool: add (fake) ram detection

[Gerd Hoffmann]

FIXME.  No idea how to figure how much ram we have.

For now claim we have 128 MB.  That is the minimum kvmtool uses
if you don't specify something via -m (if I read the code correctly).
So things should at least work, even though we might leave memory
unused.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/fw/paravirt.c | 11 +++
 src/fw/paravirt.h |  2 ++
 src/post.c|  1 +
 3 files changed, 14 insertions(+)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index db22ae8..efd9848 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -446,3 +446,14 @@ void qemu_cfg_init(void)
 dprintf(1, Moving pm_base to 0x%x\n, acpi_pm_base);
 }
 }
+
+void
+kvmtool_preinit(void)
+{
+if (!CONFIG_KVMTOOL)
+return;
+
+/* FIXME: claim we have 128 MB */
+RamSize = 128 * 1024 * 1024;
+add_e820(0, RamSize, E820_RAM);
+}
diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h
index 95ffb92..7caca4d 100644
--- a/src/fw/paravirt.h
+++ b/src/fw/paravirt.h
@@ -34,4 +34,6 @@ void qemu_preinit(void);
 void qemu_platform_setup(void);
 void qemu_cfg_init(void);
 
+void kvmtool_preinit(void);
+
 #endif
diff --git a/src/post.c b/src/post.c
index 65a3c9c..36cc5d7 100644
--- a/src/post.c
+++ b/src/post.c
@@ -314,6 +314,7 @@ dopost(void)
 {
 // Detect ram and setup internal malloc.
 qemu_preinit();
+kvmtool_preinit();
 coreboot_preinit();
 malloc_preinit();
 
-- 
1.8.3.1

--
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

[PATCH 1/7] kvmtool: initial support

[Gerd Hoffmann]

Add CONFIG_KVMTOOL, some initial preparations so seabios
at least prints some debug messages on the serial line.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 Makefile| 1 +
 src/Kconfig | 7 +++
 src/post.c  | 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index e287530..d7053a6 100644
--- a/Makefile
+++ b/Makefile
@@ -87,6 +87,7 @@ endif
 
 target-y :=
 target-$(CONFIG_QEMU) += $(OUT)bios.bin
+target-$(CONFIG_KVMTOOL) += $(OUT)bios.bin
 target-$(CONFIG_CSM) += $(OUT)Csm16.bin
 target-$(CONFIG_COREBOOT) += $(OUT)bios.bin.elf
 target-$(CONFIG_BUILD_VGABIOS) += $(OUT)vgabios.bin
diff --git a/src/Kconfig b/src/Kconfig
index 14c38fb..7620067 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -25,6 +25,12 @@ choice
Configure to be used by EFI firmware as Compatibility Support
module (CSM) to provide legacy BIOS services.
 
+config KVMTOOL
+bool Build for kvmtool
+select DEBUG_SERIAL
+help
+Configure for an emulated machine (kvmtool).
+
 endchoice
 
 config QEMU_HARDWARE
@@ -130,6 +136,7 @@ endchoice
 
 config ROM_SIZE
 int ROM size (in KB)
+default 128 if KVMTOOL
 default 0
 help
 Set the ROM size.  Say '0' here to make seabios figure the
diff --git a/src/post.c b/src/post.c
index 6157b50..65a3c9c 100644
--- a/src/post.c
+++ b/src/post.c
@@ -327,7 +327,7 @@ dopost(void)
 void VISIBLE32FLAT
 handle_post(void)
 {
-if (!CONFIG_QEMU  !CONFIG_COREBOOT)
+if (!CONFIG_QEMU  !CONFIG_COREBOOT  !CONFIG_KVMTOOL)
 return;
 
 serial_debug_preinit();
-- 
1.8.3.1

--
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

[PATCH 6/7] kvmtool: no keyboard, don't need boot menu

[Gerd Hoffmann]

seabios uses the serial line one-way.
Only debug output, no keyboard input.
So the boot menu is pointless, you can't
pick something anyway.  So turn it off.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/Kconfig b/src/Kconfig
index 2bb90c0..74d93bb 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -61,18 +61,21 @@ endchoice
 
 config BOOTMENU
 depends on BOOT
+depends on !KVMTOOL
 bool Bootmenu
 default y
 help
 Support an interactive boot menu at end of post.
 config BOOTSPLASH
 depends on BOOTMENU
+depends on !KVMTOOL
 bool Graphical boot splash screen
 default y
 help
 Support showing a graphical boot splash screen.
 config BOOTORDER
 depends on BOOT
+depends on !KVMTOOL
 bool Boot ordering
 default y
 help
-- 
1.8.3.1

--
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

[PATCH 7/7] kvmtool: support larger virtio queues

[Gerd Hoffmann]

They have 256 entries on kvmtool, support that.  Need more memory for
virtqueues now.  But with the move to 32bit drivers this should not be
a big issue.

FIXME: Must bump to 260 to make things actually work.  There seems to be
some corruption otherwise and kvmtool complains about invalid requests.
Not yet debugged who is at fault here.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/hw/virtio-ring.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h
index 7df9004..3a143e0 100644
--- a/src/hw/virtio-ring.h
+++ b/src/hw/virtio-ring.h
@@ -28,7 +28,7 @@
 /* v1.0 compliant. */
 #define VIRTIO_F_VERSION_1  32
 
-#define MAX_QUEUE_NUM  (128)
+#define MAX_QUEUE_NUM  (260)
 
 #define VRING_DESC_F_NEXT  1
 #define VRING_DESC_F_WRITE 2
-- 
1.8.3.1

--
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

[PATCH 0/7] kvmtool support for seabios

[Gerd Hoffmann]

  Hi,

Played around a bit with kvmtool.  Got annonyed because you can't just
pass it a guest image to boot from.  Decided to check what it takes to
run seabios in kvmtool, so it can load the guest kernel from the disk
image.  So, here are the results ...

There isn't much work involved at the seabios side.  Add a new config
option.  Tweak kconfig.  Some basic windup on the code.  Loads kernel
from disk.  Yea!  Success!

Well.  That only uncovers a bunch of issues in kvmtool ...

 (1) There seems to be no way to figure the amout of memory available.
 For now I've hardcoded 128 MB in seabios.  See patch #3.

 (2) Something corrupts virtio rings.  Not clear yet whenever seabios or
 kvmtool is at fault here.  See patch #7.

 (3) kvmtool doesn't emulate a pci host bridge.  Linux kernel is unhappy
 and throws an error on pci initialization.  kvmtool tackles that
 by appending pci=conf1 to the command line when booting a kernel
 directly.  Which of course doesn't fly if you wanna boot the
 fedora cloud image downloaded from the internet as-is.  Booting the
 image once in qemu to tweak the boot loader config gets over it.

 (4) Linux kernel fails on virtio-blk initialization.  Bummer.  /me
 suspects kvmtool doesn't implement proper virtio device reset,
 so the device handover from seabios to linux kernel doesn't work.

So, the kernel boots fine but fails to mount the root filesystem.  After
a while dracut decides to not wait any longer for the root filesystem to
show up and drops into the emergency shell, where you can play around a
bit.

enjoy,
  Gerd

Patches also available in the git repository at:

  git://git.kraxel.org/seabios kvmtool


Gerd Hoffmann (7):
  kvmtool: initial support
  kvmtool: tweak kconfig for emulated hardware
  kvmtool: add (fake) ram detection
  kvmtool: detect pci devices
  kvmtool: uses mmio for legacy bar 0
  kvmtool: no keyboard, don't need boot menu
  kvmtool: support larger virtio queues

 Makefile |  1 +
 src/Kconfig  | 24 ++--
 src/fw/paravirt.c| 20 
 src/fw/paravirt.h|  3 +++
 src/hw/virtio-pci.c  | 11 ---
 src/hw/virtio-ring.h |  2 +-
 src/post.c   |  4 +++-
 7 files changed, 58 insertions(+), 7 deletions(-)
--
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

[PATCH 5/7] kvmtool: uses mmio for legacy bar 0

[Gerd Hoffmann]

Hmm.  Doesn't match virtio spec.
But easy to check and handle.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/hw/virtio-pci.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/hw/virtio-pci.c b/src/hw/virtio-pci.c
index 6df5194..465deb9 100644
--- a/src/hw/virtio-pci.c
+++ b/src/hw/virtio-pci.c
@@ -267,9 +267,14 @@ void vp_init_simple(struct vp_device *vp, struct 
pci_device *pci)
 dprintf(1, pci dev %x:%x using legacy (0.9.5) virtio mode\n,
 pci_bdf_to_bus(pci-bdf), pci_bdf_to_dev(pci-bdf));
 vp-legacy.bar = 0;
-vp-legacy.addr = pci_config_readl(pci-bdf, PCI_BASE_ADDRESS_0) 
-PCI_BASE_ADDRESS_IO_MASK;
-vp-legacy.is_io = 1;
+addr = pci_config_readl(pci-bdf, PCI_BASE_ADDRESS_0);
+if (addr  PCI_BASE_ADDRESS_SPACE_IO) {
+vp-legacy.addr = addr  PCI_BASE_ADDRESS_IO_MASK;
+vp-legacy.is_io = 1;
+} else {
+vp-legacy.addr = addr  PCI_BASE_ADDRESS_MEM_MASK;
+vp-legacy.is_io = 0;
+}
 }
 
 vp_reset(vp);
-- 
1.8.3.1

--
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

[PATCH 2/7] kvmtool: tweak kconfig for emulated hardware

[Gerd Hoffmann]

Disable stuff not emulated by kvmtool, no need
to waste time and code for that.

Enable virtio-blk and virtio-scsi.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/Kconfig | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 7620067..2bb90c0 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -151,6 +151,7 @@ endmenu
 menu Hardware support
 config ATA
 depends on DRIVES
+depends on !KVMTOOL
 bool ATA controllers
 default y
 help
@@ -169,6 +170,7 @@ menu Hardware support
 Use 32bit PIO accesses on ATA (minor optimization on PCI 
transfers).
 config AHCI
 depends on DRIVES
+depends on !KVMTOOL
 bool AHCI controllers
 default y
 help
@@ -180,13 +182,13 @@ menu Hardware support
 help
 Support for SD cards on PCI host controllers.
 config VIRTIO_BLK
-depends on DRIVES  QEMU_HARDWARE
+depends on DRIVES  (QEMU_HARDWARE || KVMTOOL)
 bool virtio-blk controllers
 default y
 help
 Support boot from virtio-blk storage.
 config VIRTIO_SCSI
-depends on DRIVES  QEMU_HARDWARE
+depends on DRIVES  (QEMU_HARDWARE || KVMTOOL)
 bool virtio-scsi controllers
 default y
 help
@@ -217,12 +219,14 @@ menu Hardware support
 Support boot from qemu-emulated lsi53c895a scsi storage.
 config MEGASAS
 depends on DRIVES
+depends on !KVMTOOL
 bool LSI MegaRAID SAS controllers
 default y
 help
 Support boot from LSI MegaRAID SAS scsi storage.
 config FLOPPY
 depends on DRIVES
+depends on !KVMTOOL
 bool Floppy controller
 default y
 help
@@ -230,6 +234,7 @@ menu Hardware support
 
 config PS2PORT
 depends on KEYBOARD || MOUSE
+depends on !KVMTOOL
 bool PS/2 port
 default y
 help
@@ -237,6 +242,7 @@ menu Hardware support
 
 config USB
 bool USB
+depends on !KVMTOOL
 default y
 help
 Support USB devices.
@@ -323,6 +329,7 @@ menu Hardware support
 help
 Initialize the Memory Type Range Registers (on emulators).
 config PMTIMER
+depends on !KVMTOOL
 bool Use ACPI timer
 default y
 help
@@ -367,6 +374,7 @@ menu BIOS interfaces
 config OPTIONROMS
 bool Option ROMS
 default y
+depends on !KVMTOOL
 help
 Support finding and running option roms during POST.
 config OPTIONROMS_DEPLOYED
@@ -437,6 +445,7 @@ menu BIOS interfaces
 
 config TCGBIOS
 depends on S3_RESUME
+depends on !KVMTOOL
 bool TPM support and TCG BIOS extensions
 default y
 help
@@ -464,6 +473,7 @@ menu BIOS Tables
 sometimes called DMI.
 config ACPI
 bool ACPI
+depends on !KVMTOOL
 default y
 help
 Support generation of ACPI tables.
-- 
1.8.3.1

--
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

[PATCH 4/7] kvmtool: detect pci devices

[Gerd Hoffmann]

Make a pci bus scan, so we find the virtio devices.
Tested with virtio-blk only (kvmtool uses that by default).

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/fw/paravirt.c | 9 +
 src/fw/paravirt.h | 1 +
 src/post.c| 1 +
 3 files changed, 11 insertions(+)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index efd9848..28d47d2 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -457,3 +457,12 @@ kvmtool_preinit(void)
 RamSize = 128 * 1024 * 1024;
 add_e820(0, RamSize, E820_RAM);
 }
+
+void
+kvmtool_platform_setup(void)
+{
+if (!CONFIG_KVMTOOL)
+return;
+
+pci_probe_devices();
+}
diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h
index 7caca4d..3078af6 100644
--- a/src/fw/paravirt.h
+++ b/src/fw/paravirt.h
@@ -35,5 +35,6 @@ void qemu_platform_setup(void);
 void qemu_cfg_init(void);
 
 void kvmtool_preinit(void);
+void kvmtool_platform_setup(void);
 
 #endif
diff --git a/src/post.c b/src/post.c
index 36cc5d7..f6b8b8e 100644
--- a/src/post.c
+++ b/src/post.c
@@ -173,6 +173,7 @@ platform_hardware_setup(void)
 
 // Platform specific setup
 qemu_platform_setup();
+kvmtool_platform_setup();
 coreboot_platform_setup();
 
 // Initialize TPM
-- 
1.8.3.1

--
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] Announcing qboot, a minimal x86 firmware for QEMU

[Gerd Hoffmann]

On Fr, 2015-05-22 at 12:21 +0100, Peter Maydell wrote:
 On 22 May 2015 at 12:12, Daniel P. Berrange berra...@redhat.com wrote:
  Yep, it is hard saying no - but I'd think as long as it was possible to add
  the extra features using -device, it ought to be practical to keep a virt
  machine types -nodefaults -nodefconfig base setup pretty minimal.
 
 Mmm, but -device only works for pluggable devices really. We don't
 have a coherent mechanism for saying put the PS/2 keyboard controller
 into the system at its usual IO ports on the command line.

Do we need that in the first place?
You can plugin a usb keyboard today.
You'll be able to plugin a virtio keyboard soon.

I think alot of hardware where this applies to is the legacy stuff we
want to get rid of for '-M virt' ...

cheers,
  Gerd


--
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] Announcing qboot, a minimal x86 firmware for QEMU

[Gerd Hoffmann]

  Hi,

 qboot is available at git://github.com/bonzini/qboot.git.

Firmware repo has packages now.

https://www.kraxel.org/repos/firmware.repo
https://www.kraxel.org/repos/jenkins/qboot/

enjoy,
  Gerd


--
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 emulation failure with recent kernel and QEMU Seabios

[Gerd Hoffmann]

On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote:
 Jan Kiszka jan.kis...@siemens.com writes:
 
  Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
  On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
  Hi,
 
  apparently since the latest QEMU updates I'm getting this once in a
  while:
  
  http://www.seabios.org/pipermail/seabios/2015-March/008897.html
 
  OK... So we are waiting on a stable release to pull in new binaries with
  this fix? A matter of days?
 
 1.8.1 is now available on the downloads page.

I know, I've uploaded it ;)

Pull request for the update was sent yesterday too.
It's merged meanwhile, so go fetch qemu master and be happy.

cheers,
  Gerd


--
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 emulation failure with recent kernel and QEMU Seabios

[Gerd Hoffmann]

On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
 Hi,
 
 apparently since the latest QEMU updates I'm getting this once in a
 while:

http://www.seabios.org/pipermail/seabios/2015-March/008897.html

cheers,
  Gerd


--
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] KVM emulation failure with recent kernel and QEMU Seabios

[Gerd Hoffmann]

On Do, 2015-03-12 at 09:14 +0100, Jan Kiszka wrote:
 Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
  On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
  Hi,
 
  apparently since the latest QEMU updates I'm getting this once in a
  while:
  
  http://www.seabios.org/pipermail/seabios/2015-March/008897.html
 
 OK... So we are waiting on a stable release to pull in new binaries with
 this fix? A matter of days?

My plan is to have a seabios 1.8.1 release ready in time for -rc0
(planned for 2014-03-17 atm).

cheers,
  Gerd


--
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: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Gerd Hoffmann]

On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
 On 12/05/2014 04:50 PM, Gerd Hoffmann wrote:
  A few comments on the kernel stuff (brief look so far, also
  compile-tested only, intel gfx on my test machine is too old).
 
* Noticed the kernel bits don't even compile when configured as
  module.  Everything (vgt, i915, kvm) must be compiled into the
  kernel.
 
 Yes, that's planned to be done along with separating hypervisor-related
 code from vgt.

Good.

  What are the exact requirements for the device?  Must it match the host
  exactly, to not confuse the guest intel graphics driver?  Or would
  something more recent -- such as the q35 emulation qemu has -- be good
  enough to make things work (assuming we add support for the
  graphic-related pci config space registers there)?
 
 
 I don't know that is exactly needed, we also need to have Windows
 driver considered.  However, I'm quite confident that, if things gonna
 work for IGD passthrough, it gonna work for GVT-g.

I'd suggest to focus on q35 emulation.  q35 is new enough that a version
with integrated graphics exists, so the gap we have to close is *much*
smaller.

In case guests expect a northbridge matching the chipset generation of
the graphics device (which I'd expect is the case, after digging a bit
in the igd and agpgart linux driver code) I think we should add proper
device emulation for them, i.e. comply q35-pcihost with
sandybridge-pcihost + ivybridge-pcihost + haswell-pcihost instead of
just copying over the pci ids from the host.  Most likely all those
variants can share most of the emulation code.

SeaBIOS then can just get support for these three northbridge variants,
so we don't need magic pci id switching hacks at all.

  The patch also adds a dummy isa bridge at 0x1f.  Simliar question here:
  What exactly is needed here?  Would things work if we simply use the q35
  lpc device here?

 Ditto.

Ok.  Lets try to just use the q35 emulation + q35 lpc device then
instead of adding a second dummy lpc device.

cheers,
  Gerd


--
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: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Gerd Hoffmann]

  Hi,

   In KVMGT, we need to register an iodev only *after* BAR 
 registers are
   written by guest.

Oh, the guest can write the bar register at any time.  Typically it
happens at boot only, but it can also happen at runtime, for example on
reboot.

I've also seen the kernel redoing the pci mappings created by the bios,
due to buggy _crs declarations in the qemu acpi tables.

   
 https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

/me goes read this.

A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).

 * Noticed the kernel bits don't even compile when configured as
   module.  Everything (vgt, i915, kvm) must be compiled into the
   kernel.
 * Design approach still seems to be i915 on vgt not the other way
   around.

Qemu/SeaBIOS bits:

I've seen the host bridge changes identity from i440fx to
copy-pci-ids-from-host.  Guess the reason for this is that seabios uses
this device to figure whenever it is running on i440fx or q35.  Correct?

What are the exact requirements for the device?  Must it match the host
exactly, to not confuse the guest intel graphics driver?  Or would
something more recent -- such as the q35 emulation qemu has -- be good
enough to make things work (assuming we add support for the
graphic-related pci config space registers there)?

The patch also adds a dummy isa bridge at 0x1f.  Simliar question here:
What exactly is needed here?  Would things work if we simply use the q35
lpc device here?

more to come after I've read the paper linked above ...

cheers,
  Gerd


--
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 audio device troubles

[Gerd Hoffmann]

  Hi,

  I pass throught the usb audio device (logitech h800 USB 046d:0a29) and
  it is seen as a device in windows.  then I hear the headset sync-up
  beeps and the device vanishes from windows.  pointers as to what I
  should look at next?
 
  Adding back Hans and Gerd...
 
  Eric are you using usb-host redirection, or Spice's usb network redir ?
 
 Host redirection I assume. It was from the collection of devices UI and 
 I added the device to pass through from the list of host USB devices.

Sounds like virt-manager.  qemu logs should be
at /var/log/libvirt/qemu/$guest.log then.  Any error messages in there?

Any messages in the host kernel log (about usb device reset maybe?)

Do you use an usb 2 controller?  If not, can try whenever that improves
things?  Can be switched when you pick the controller usb in the
virt-manager devices ui.

cheers,
  Gerd


--
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: [Xen-devel] Xen hypervisor inside KVM guest with x2apic CPU feature fails to boot

[Gerd Hoffmann]

  Hi,

  (XEN) 
  (XEN) Panic on CPU 0:
  (XEN) IO-APIC + timer doesn't work!  Boot with apic_verbosity=debug and 
  send a report.  Then try booting with the 'noapic' option
  (XEN) 
 

Just tried the same a few days ago.  Adding a second vcpu made things
work.

 I am going to go out on a limb and say it is unlikely for the Xen side
 of things to be broken.  We have machines in XenServers test lab which
 support x2apic but have it disabled in this manor because of a lack of
 EIM (or due to errata).

I'm not so sure.  non-SMP setup with x2apic is probably pretty rare on
physical hardware and I wouldn't be surprised if that happens to hit a
untested code path in Xen ...

 I would look into what KVM/qemu does differently as a result of the
 +x2apic flag, and whether it is simply the reported cpuid feature, or
 whether it affects the legacy ioapic emulation.

... but enabling x2apic for a guest depending on legacy ioapic stuff is
pretty unlikely too, so that setup being emulated incorrectly without
being noticed so far wouldn't surprise me too.

cheers,
  Gerd


--
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 and Windows guests

[Gerd Hoffmann]

 1. I plug in the phone and do an lsusb:
 Bus 003 Device 03: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 
 Phone [Galaxy S II], GT-I9300 Phone [Galaxy S III], GT-P7500 [Galaxy Tab 
 10.1] , GT-I9500 [Galaxy S 4]

 2. I create the proper configuration in my qemu command line:
 -usb -device usb-host,hostbus=3,hostaddr=3

 When I start the VM, the USB jumps to another hostaddr, and it is not 
 available to the guest.

Probably the phone disconnects, then re-appears with a different
configuration.  Using hostport=... instead of hostaddr should fix it.

cheers,
  Gerd


--
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?

[Gerd Hoffmann]

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?

cheers,
  Gerd


--
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

kvm smm mode support?

[Gerd Hoffmann]

  Hi,

Anyone has plans to add smm support to kvm?

We have two potential use cases meanwhile:

 (1) OVMF could use it to implement the LockBox (storage area the
 OS can't tamper with, needed to make secure boot actually secure).

 (2) SeaBIOS considers using a SMM trampoline to switch into 32bit mode
 for device drivers.  See
http://www.seabios.org/pipermail/seabios/2014-April/007957.html

cheers,
  Gerd


--
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] [ANNOUNCE] Key Signing Party at KVM Forum 2013

[Gerd Hoffmann]

  Hi,

 I synced to hkp://pgp.mit.edu.
 
 Key ID: 81AB73C8
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9CA4ABB381AB73C8

I think the key servers sync to each other anyway,
so it doesn't matter much which one you pick.

cheers,
  Gerd


--
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

[Gerd Hoffmann]

On 06/06/13 08:34, Gleb Natapov wrote:
 On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote:

 Oh, you mean in real mode.

 SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout.
 There are loads of ASSERT32FLAT()s in the code to make sure of this.

 Well, not exactly. Initialization is done in 32bit, but disk
 reads/writes are done in 16bit mode since it should work from int13
 interrupt handler.

Exactly.  It's only the initialization code which has ASSERt32FLAT()
all over the place.  Which actually is the majority of the code in most
cases as all the hardware detection and initialization code is there.
But kicking I/O requests must work from 16bit mode too.

 The only way I know to access MMIO bars from 16 bit
 is to use SMM which we do not have in KVM.

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.

But as hpa mentioned it will be more tricky for option roms (aka
virtio-net).

cheers,
  Gerd


--
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

[Gerd Hoffmann]

  Hi,

 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?

Don't know the details of that magic.  Kevin had some concerns on the
stability of this, so maybe there is a theoretic hole.  So far I havn't
seen any issues in practice, but also didn't stress it too much.
Basically only used that with all kinds of boot loaders, could very well
be it breaks if you try to use that with more esoteric stuff such as dos
extenders, then hit unhandled corner cases ...

cheers,
  Gerd


--
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] [SeaBIOS] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

On 06/01/13 01:01, Jordan Justen wrote:
 On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kra...@redhat.com wrote:
   Hi,

 I guess -bios would load coreboot. Coreboot would siphon the data
 necessary for ACPI table building through the current (same) fw_cfg
 bottleneck, build the tables,

 Yes.
 
 So, this is really about making coreboot+seabios the default QEMU
 firmware, and making seabios depend on being a coreboot payload?

I still think it's better to simply have qemu generate the acpi tables,
but if that isn't going to be accepted we should seriously consider 
evaluate switching to coreboot.

 load the boot firmware (SeaBIOS or OVMF or
 something else -- not sure how to configure that),
 
 It wouldn't be loading OVMF. It would be loading CorebootPkg.

Yep.  Some OVMF bits would be needed though (virtio drivers, qemu boot
priority support, ...).

cheers,
  Gerd

--
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] [SeaBIOS] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

  Hi,

 I guess -bios would load coreboot. Coreboot would siphon the data
 necessary for ACPI table building through the current (same) fw_cfg
 bottleneck, build the tables,

Yes.

 load the boot firmware (SeaBIOS or OVMF or
 something else -- not sure how to configure that),

The coreboot rom has named sections (this is called cbfs which stands
for coreboot filesystem IIRC):

rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print
bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0
alignment: 64 bytes

Name   Offset Type Size
cmos_layout.bin0x0cmos_layout  1160
fallback/romstage  0x4c0  stage14419
fallback/coreboot_ram  0x3d80 stage37333
config 0xcfc0 raw  2493
fallback/payload   0xd9c0 payload  56969
vgabios/sgabios0x1b8c0raw  4096
(empty)0x1c900null 144216

where fallback/payload is seabios.

 and pass down the
 tables to the firmware (through a now unspecified interface -- perhaps
 the tables could even be installed at this point).

As far I know coreboot can add more stuff such as acpi tables to cbfs at
runtime and seabios able to access cbfs too and pull informations from
coreboot that way.

HTH,
  Gerd


--
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

[Gerd Hoffmann]

On 05/31/13 10:13, 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.

Indeed.

 ACPI bytes are obviously a function of QEMU configuration. QEMU
 configuration can be changed through a great many channels, so it
 makes sense to me that QEMU itself would take care of generating
 correct ACPI, rather than exporting it's own data structures and
 pushing the ACPI problem onto the firmware, especially considering
 the desire for multiple independent firmware implementations.

Can't agree more.

I still think the best solution is to have qemu generate the acpi tables
and all firmware can just grab them.

Second best option would be to have coreboot generate them and
everything else go on top of coreboot then.

Third best option is to duplicate the acpi generation code in all
firmware variants (this is what we have today).

IMO qvmloader would be even worse than these three.  Writing a piece of
firmware is alot more tricky than a linux userspace app, especially in
x86 land with the funky mode switching and assembler modes.

cheers,
  Gerd


--
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

[Gerd Hoffmann]

  Hi,

 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?  Seems like it would be
 more or less a copy/paste once we had a proper implementation in QEMU.

Well, no.  Firmware is a quite simple environment without standard libc
etc, so moving code from qemu to firmware certainly isn't as easy as
copying over a file.

 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.

 Certainly an option, but that is a long-term project.
 
 Out of curiousity, are there other benefits to using coreboot as a core
 firmware in QEMU?

Short-term it's alot of work as we have to bring coreboot's qemu support
to feature parity with seabios.  I suspect most of this is acpi related
though, so when qemu provides the tables and coreboot uses them we could
be pretty close already.

Long-term it should simplify firmware maintainance as we have only *one*
place which handles the hardware bringup, and seabios/ovmf have less
work to do.

 Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?

I wouldn't be surprised if people start using other coreboot payloads
and/or features such as direct linux kernel boot once it works well on qemu.

We might even run qemu test suites as coreboot payload.

cheers,
  Gerd


--
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] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

  Hi,

 Why should this be true?  Shouldn't we be allowed to increase the amount
 of memory the guest has across reboots?  That's equivalent to adding
 another DIMM after power off.

poweroff is equivalent to exiting qemu, not to guest reset.

 Not generating tables on reset does limit what we can do in a pretty
 fundamental way.  Even if you can argue it in the short term, I don't
 think it's viable in the long term.

I don't think so.  The procedure for adding/removing non-hotpluggable
hardware is:  poweroff, plugin/-out hardware (change config in qemu),
boot.  Hotpluggable hardware doesn't need acpi table updates.

cheers,
  Gerd

--
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

[Gerd Hoffmann]

On 05/29/13 01:53, Kevin O'Connor wrote:
 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,

I fail to see the security issues here.  It's not like the apci table
generation code operates on untrusted input from the guest ...

 complexities in running iasl on
 big-endian machines,

We already have a bunch of prebuilt blobs in the qemu repo for simliar
reasons, we can do that with iasl output too.

 possible complexity of having to regenerate
 tables on a vm reboot,

Why tables should be regenerated at reboot?  I remember hotplug being
mentioned in the call.  Hmm?  Which hotplugged component needs acpi
table updates to work properly?  And what is the point of hotplugging if
you must reboot the guest anyway to get the acpi updates needed?
Details please.

Also mentioned in the call: architectural reasons, which I understand
as real hardware works that way.  Correct.  But qemu's virtual
hardware is configurable in more ways than real hardware, so we have
different needs.  For example: pci slots can or can't be hotpluggable.
On real hardware this is fixed.  IIRC this is one of the reasons why we
have to patch acpi tables.

 overall sloppiness of doing it in QEMU.

/me gets the feeling that this is the *main* reason, given that the
other ones don't look very convincing to me.

 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.

 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.

Certainly an option, but that is a long-term project.

 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).

Also simliar to the coreboot idea.

Also in the call: The idea of having some library for acpi table
generation provided by qemu which the firmware can use.  Has license
compatibility issues.  Also difficult due to the fact that there is no
libc in firmware, so such a library would need firmware-specific
abstraction layers even for simple stuff such as memory allocation.

 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.

Good.  I think having qemu generate the tables is also quite useful for
evaluating the move to coreboot:

  (1)  make qemu generate the acpi tables.
  (2a) make seabios use the qemu-generated tables.
  (2b) make ovmf use the qemu-generated tables.
  (2c) make coreboot use the qemu-generated tables.

Now we can look where we stand when using coreboot+seabios or
coreboot+tianocore compared to bare seabios / bare ovmf.  I expect there
are quite a few things to fix until the coreboot+seabios combo runs
without regressions compared to bare seabios.  But maybe not when qemu
provides the acpi tables to coreboot.

In case the coreboot testdrive works out well we can continue with:

  (3)  use coreboot+seabios by default.
  (4)  move acpi table generation from qemu to coreboot.

cheers,
  Gerd


--
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

[Gerd Hoffmann]

  Hi,

 possible complexity of having to regenerate
 tables on a vm reboot,

 Why tables should be regenerated at reboot?  I remember hotplug being
 mentioned in the call.  Hmm?  Which hotplugged component needs acpi
 table updates to work properly?  And what is the point of hotplugging if
 you must reboot the guest anyway to get the acpi updates needed?
 Details please.
 
 I think it's a mistake. I sent a mail explaining this part.

Saw it meanwhile.

 Also mentioned in the call: architectural reasons, which I understand
 as real hardware works that way.  Correct.
 
 Not exactly. Real hardware is very likely to have
 most of the tables pre-generated in ROM, load
 them and tweak them in the minor way.

From a quick look it seems coreboot has a static (iasl-compiled) dsdt
and generates everything else.

http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/emulation/qemu-x86/acpi_tables.c

 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.
 
 Did you look at the patchset I posted?

Very briefly only.

 Generation is in a standalone C file there.

Good.

 However, if you mean we should do things like
 
 if (Device_id == foobar) {
 }
 in once central place, I disagree.
 I think that's nasty, adding devices would
 mean touching this central registry.

No, I mean more lookup PIIX4_PM object + check disable_s3 property
instead of having code for it in hw/acpi/piix4.c or using global variables.

cheers,
  Gerd


--
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] reply: reply: qemu crashed when starting vm(kvm) with vnc connect

[Gerd Hoffmann]

On 04/11/13 11:29, Stefan Hajnoczi wrote:
 On Mon, Apr 08, 2013 at 12:27:06PM +, Zhanghaoyu (A) wrote:
 On Sun, Apr 07, 2013 at 04:58:07AM +, Zhanghaoyu (A) wrote:
 I start a kvm VM with vnc(using the zrle protocol) connect, sometimes 
 qemu program crashed during starting period, received signal SIGABRT.
 Trying about 20 times, this crash may be reproduced.
 I guess the cause memory corruption or double free.

 Which version of QEMU are you running?

 Please try qemu.git/master.

Please try again with latest master, might be fixed meanwhile.

If it still happens pleas provide full qemu and vnc client command lines.

 backtrace from core file is shown as below:

 Program received signal SIGABRT, Aborted.

 #8  0x7f32efd26d07 in vnc_disconnect_finish (vs=0x7f32f0c762d0)
 at ui/vnc.c:1050

Do you have a vnc client connected?  Do you close it?

Any errors reported by the vnc client (maybe it disconnects due to an
error in the data stream)?

cheers,
  Gerd


--
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] Virtualbox svga card in KVM

[Gerd Hoffmann]

On 04/08/13 17:11, Peter Maydell wrote:
 On 6 April 2013 00:52, Sriram Murthy srira...@yahoo.com wrote:
 (actually, the virtualbox SVGA card is based off of the KVM VGA card)
 
 Is it possible to implement it as an extension to the VGA
 card device, or has it diverged incompatibly such that it
 has to be its own separate device model?

Not needed.  One just has to go write a windows driver.  The virtual
hardware can handle any resolution just fine.

cheers,
  Gerd


--
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] QEMU buildbot maintenance state

[Gerd Hoffmann]

  Hi,

 Gerd: Are you willing to co-maintain the QEMU buildmaster with Daniel
 and Christian?  It would be awesome if you could do this given your
 experience running and customizing buildbot.

I'll try to set aside some time for that.  Christians idea to host the
config at github is good, that certainly makes it easier to balance
things to more people.

Another thing which would be helpful:  Any chance we can setup a
maintainer tree mirror @ git.qemu.org?  A single repository where each
maintainer tree shows up as a branch?

This would make the buildbot setup *alot* easier.  We can go for a
AnyBranchScheduler then with BuildFactory and BuildConfig shared,
instead of needing one BuildFactory and BuildConfig per branch.  Also
makes the buildbot web interface less cluttered as we don't have a
insane amount of BuildConfigs any more.  And saves some resources
(bandwidth + diskspace) for the buildslaves.

I think people who want to look what is coming or who want to test stuff
cooking it would be a nice service too if they have a one-stop shop
where they can get everything.

cheers,
  Gerd
--
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] KVM call minutes 2013-01-29 - Port I/O

[Gerd Hoffmann]

  Hi,

 hw/qxl.c:portio_list_add(qxl_vga_port_list,
 pci_address_space_io(dev), 0x3b0);
 hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);

That reminds me I should solve this in a more elegant way.

qxl takes over the vga io ports.  The reason it does this is because qxl
switches into vga mode in case the vga ports are accessed while not in
vga mode.  After doing the check (and possibly switching mode) the vga
handler is called to actually handle it.

That twist makes it a bit hard to convert vga ...

Anyone knows how one would do that with the memory api instead? I think
taking over the ports is easy as the memory regions have priorities so I
can simply register a region with higher priority. I have no clue how to
forward the access to the vga code though.

Anyone has clues / suggestions?

thanks,
  Gerd

--
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: External USB Hub.

[Gerd Hoffmann]

On 11/09/12 13:23, Veruca Salt wrote:
 
 
 I'm pretty sure the answer to this is 'no', but does the ehci implementation 
 support USB-connected USB hubs?
 Or will that come out in 1.2 in the xhci implementation.

No.  You can try using the emulated hub and hook up the devices
connected to the hub one by one if they have to be connected to a hub.

Only problem with that is that the emulated hub is a usb 1.1 device. You
can also try connecting all devices to the ehci root hub, this will
allow them run with usb2 speed.

cheers,
  Gerd

--
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

[Gerd Hoffmann]

  Hi,

 I just want to enable 64 bit bars for KVM usage, seabios 1.7.0 is
 used in current qemu-kvm, which not handle 64 bit bars yet. I cloned
 seabios code from kernel.org(seems no 64 bit bars supporting), but I
 was not taking notice of the tree on http://git.qemu.org/, yes it has
 already done 64 bit bars handling. So you may ignore this patch.
 
 Btw, when will the latest seabios(especially 64 bits bars) be
 involved qemu-kvm?

qemu 1.2.0 has it (seabios 1.7.1, a git snapshot very close to it to be
exact), and qemu-kvm 1.2.0 should have it too.

cheers,
  Gerd
--
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

[Gerd Hoffmann]

On 11/02/12 06:42, 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.

What problem you are trying to fix?  The existing code should handle
64bit bars just fine.  By default they are placed below 4G though for
compatibility reasons (make old 32bit guests happy).  When running out
of address space seabios will try map them above 4G though to make room
below 4G.

Mapping your 64bit PCI bars above 4G unconditionally (for testing or
other reasons) can simply be done this way:

--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -599,7 +599,7 @@ static void pci_bios_map_devices(struct pci_bus *busses)
 {
 pcimem_start = RamSize;

-if (pci_bios_init_root_regions(busses)) {
+if (1 /* pci_bios_init_root_regions(busses) */) {
 struct pci_region r64_mem, r64_pref;
 r64_mem.list = NULL;
 r64_pref.list = NULL;

We might want add a config option for this.

cheers,
  Gerd

--
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] apic: always update the in-kernel status after loading

[Gerd Hoffmann]

  Hi,

 I think deferring IRQ events to the point when the complete vmstate is
 loaded is the cleaner and more robust approach.

Agree.  Just schedule a bh in post_load.
See also a229c0535bd336efaec786dd6e352a54e0a8187d

cheers,
  Gerd
--
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] apic: always update the in-kernel status after loading

[Gerd Hoffmann]

On 11/02/12 16:13, Paolo Bonzini wrote:
 Hi,

 I think deferring IRQ events to the point when the complete vmstate
 is
 loaded is the cleaner and more robust approach.

 Agree.  Just schedule a bh in post_load.
 See also a229c0535bd336efaec786dd6e352a54e0a8187d
 
 No, it cannot a bh.  Right now incoming migration is blocking,
 but this will change in 1.3.  There is no guarantee that a
 bottom half will run after migration has completed.

Then we'll need some new way to do this, maybe a new post_load handler
which is called once _all_ state is loaded.

cheers,
  Gerd

--
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] Using PCI config space to indicate config location

[Gerd Hoffmann]

  Hi,

 Well, we also want to clean up the registers, so how about:

 BAR0: legacy, as is.  If you access this, don't use the others.

Ok.

 BAR1: new format virtio-pci layout.  If you use this, don't use BAR0.
 BAR2: virtio-cfg.  If you use this, don't use BAR0.

Why use two bars for this?  You can put them into one mmio bar, together
with the msi-x vector table and PBA.  Of course a pci capability
describing the location is helpful for that ;)

 BAR3: ISR. If you use this, don't use BAR0.

Again, I wouldn't hardcode that but use a capability.

 I prefer the cases exclusive (ie. use one or the other) as a clear path
 to remove the legacy layout; and leaving the ISR in BAR0 leaves us with
 an ugly corner case in future (ISR is BAR0 + 19?  WTF?).

Ok, so we have four register sets:

  (1) legacy layout
  (2) new virtio-pci
  (3) new virtio-config
  (4) new virtio-isr

We can have a vendor pci capability, with a dword for each register set:

  bit  31-- present bit
  bits 26-24 -- bar
  bits 23-0  -- offset

So current drivers which must support legacy can use this:

  legacy layout -- present, bar 0, offset 0
  new virtio-pci-- present, bar 1, offset 0
  new virtio-config -- present, bar 1, offset 256
  new virtio-isr-- present, bar 0, offset 19

[ For completeness: msi-x capability could add this: ]

  msi-x vector tablebar 1, offset 512
  msi-x pba bar 1, offset 768

 We'll never remove legacy so we shouldn't plan on it.  There are
 literally hundreds of thousands of VMs out there with the current virtio
 drivers installed in them.  We'll be supporting them for a very, very
 long time :-)

But new devices (virtio-qxl being a candidate) don't have old guests and
don't need to worry.

They could use this if they care about fast isr:

  legacy layout -- not present
  new virtio-pci-- present, bar 1, offset 0
  new virtio-config -- present, bar 1, offset 256
  new virtio-isr-- present, bar 0, offset 0

Or this if they don't worry about isr performance:

  legacy layout -- not present
  new virtio-pci-- present, bar 0, offset 0
  new virtio-config -- present, bar 0, offset 256
  new virtio-isr-- not present

 I don't think we gain a lot by moving the ISR into a separate BAR.
 Splitting up registers like that seems weird to me too.

Main advantage of defining a register set with just isr is that it
reduces pio address space consumtion for new virtio devices which don't
have to worry about the legacy layout (8 bytes which is minimum size for
io bars instead of 64 bytes).

 If we added an additional constraints that BAR1 was mirrored except for

Why add constraints?  We want something future-proof, don't we?

 The detection is simple: if BAR1 has non-zero length, it's new-style,
 otherwise legacy.

Doesn't fly.  BAR1 is in use today for MSI-X support.

 I agree that this is the best way to extend, but I think we should still
 use a transport feature bit.  We want to be able to detect within QEMU
 whether a guest is using these new features because we need to adjust
 migration state accordingly.

Why does migration need adjustments?

[ Not that I want veto a feature bit, but I don't see the need yet ]

cheers,
  Gerd
--
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] Using PCI config space to indicate config location

[Gerd Hoffmann]

  Hi,

 Why use two bars for this?  You can put them into one mmio bar, together
 with the msi-x vector table and PBA.  Of course a pci capability
 describing the location is helpful for that ;)
 
 You don't need a capability.  You can also just add a config offset
 field to the register set and then make the semantics that it occurs in
 the same region.

Yes, that will work too.  Removes some freedom to place the register
ranges, but given that we don't want burn bars and thus prefer to place
everything into a single mmio bar that shouldn't be an issue.  Real
hardware does this too btw (xhci for example).

 Main advantage of defining a register set with just isr is that it
 reduces pio address space consumtion for new virtio devices which don't
 have to worry about the legacy layout (8 bytes which is minimum size for
 io bars instead of 64 bytes).
 
 Doing some rough math, we should have at least 16k of PIO space.  That
 let's us have well over 500 virtio-pci devices with the current register
 layout.

I've seen worries nevertheless, but given we have virtio-scsi now which
can handle lots of disks without needing lots of virtio-pci devices it
is probably not that a big issue any more.

 The detection is simple: if BAR1 has non-zero length, it's new-style,
 otherwise legacy.

 Doesn't fly.  BAR1 is in use today for MSI-X support.
 
 But the location is specified via capabilities so we can change the
 location to be within BAR1 at a non-conflicting offset.

Sure.  Nevertheless BAR1 has non-zero length can't be used to detect
new-style virtio as old-style devices already have BAR1 with a non-zero
length.

So how about this:

(1) Add a vendor specific pci capability for new-style virtio.
Specifies the pci bar used for new-style virtio registers.
Guests can use it to figure whenever new-style virtio is
supported and to map the correct bar (which will probably
be bar 1 in most cases).

(2) Have virtio-offsets register set, located at the new-style bar,
offset 0:

struct virtio_offsets {
   __le32 num_offsets;// so we can extend this later
   __le32 virtio_pci_offset;  // location of virtio-pci registers
   __le32 virtio_cfg_offset;  // location of virtio config space
};

(3) place virtio-pci registers (same as 0..23 in bar 0) in the new-style
bar, offset virtio_pci_offset

(4) place virtio config space (same as 20+/24+ in bar 0) in the
new-style bar, offset virtio_cfg_offset

cheers,
  Gerd
--
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] Using PCI config space to indicate config location

[Gerd Hoffmann]

  Hi,

 But I think we could solve this in a different way.  I think we could
 just move the virtio configuration space to BAR1 by using a transport
 feature bit.

Why hard-code stuff?

I think it makes alot of sense to have a capability simliar to msi-x
which simply specifies bar and offset of the register sets:

[root@fedora ~]# lspci -vvs4
00:04.0 SCSI storage controller: Red Hat, Inc Virtio block device
[ ... ]
Region 0: I/O ports at c000 [size=64]
Region 1: Memory at fc029000 (32-bit) [size=4K]
Capabilities: [40] MSI-X: Enable+ Count=2 Masked-
Vector table: BAR=1 offset=
PBA: BAR=1 offset=0800

So we could have for virtio something like this:

Capabilities: [??] virtio-regs:
legacy: BAR=0 offset=0
virtio-pci: BAR=1 offset=1000
virtio-cfg: BAR=1 offset=1800

 That then frees up the entire BAR0 for use as virtio-pci registers.  We
 can then always include the virtio-pci MSI-X register space and
 introduce all new virtio-pci registers as simply being appended.

BAR0 needs to stay as-is for compatibility reasons.  New devices which
don't have to care about old guests don't need to provide a 'legacy'
register region.

Most devices have mmio at BAR1 for msi-x support anyway, we can place
the virtio-pci and virtio configuration registers there too by default.
 I wouldn't hardcode that though.

 This new feature bit then becomes essentially a virtio configuration
 latch.  When unacked, virtio configuration hides new registers, when
 acked, those new registers are exposed.

I'd just expose them all all the time.

 2) ISTR an argument about mapping the ISR register separately, for
performance, but I can't find a reference to it.
 
 I think the rationale is that ISR really needs to be PIO but everything
 else doesn't.  PIO is much faster on x86 because it doesn't require
 walking page tables or instruction emulation to handle the exit.

Is this still a pressing issue?  With MSI-X enabled ISR isn't needed,
correct?  Which would imply that pretty much only old guests without
MSI-X support need this, and we don't need to worry that much when
designing something new ...

cheers,
  Gerd
--
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] Using PCI config space to indicate config location

[Gerd Hoffmann]

  Hi,

 So we could have for virtio something like this:

 Capabilities: [??] virtio-regs:
 legacy: BAR=0 offset=0
 virtio-pci: BAR=1 offset=1000
 virtio-cfg: BAR=1 offset=1800
 
 This would be a vendor specific PCI capability so lspci wouldn't
 automatically know how to parse it.

Sure, would need a patch to actually parse+print the cap,
/me was just trying to make my point clear in a simple way.

 2) ISTR an argument about mapping the ISR register separately, for
performance, but I can't find a reference to it.

 I think the rationale is that ISR really needs to be PIO but everything
 else doesn't.  PIO is much faster on x86 because it doesn't require
 walking page tables or instruction emulation to handle the exit.

 Is this still a pressing issue?  With MSI-X enabled ISR isn't needed,
 correct?  Which would imply that pretty much only old guests without
 MSI-X support need this, and we don't need to worry that much when
 designing something new ...
 
 It wasn't that long ago that MSI-X wasn't supported..  I think we should
 continue to keep ISR as PIO as it is a fast path.

No problem if we allow to have both legacy layout and new layout at the
same time.  Guests can continue to use ISR @ BAR0 in PIO space for
existing virtio devices, even in case they want use mmio for other
registers - all fine.

New virtio devices can support MSI-X from day one and decide to not
expose a legacy layout PIO bar.

cheers,
  Gerd

--
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] vga: add mmio bar to standard vga

[Gerd Hoffmann]

 + *   0x0400 - 0x041f  vga ioports (0x3c0 - 0x3df), remapped 1:1
 
 Do they support word accesses to set both index and data?
 
 + *   0x0500 - 0x0515  bochs dispi interface registers, mapped flat without
 + * index/data ports.  Use (index  1) as offset for
 + * (16bit) register access.
 + */
 
 BAR should disappear with -M old.

Sure.  I have a patch in flight which adds the pc-1.3 machine type, once
this is in I can easily add the compat stuff.

 +static const MemoryRegionOps pci_vga_ioport_ops = {
 +.read = pci_vga_ioport_read,
 +.write = pci_vga_ioport_write,
 +.valid.min_access_size = 1,
 +.valid.max_access_size = 4,
 +.impl.min_access_size = 1,
 +.impl.max_access_size = 1,
 +.endianness = DEVICE_LITTLE_ENDIAN,
 +};
 
 Looks like word writes are supported provided the memory API breaks up
 writes in little endian order.  Better to make it explicit.

Like the attached incremental patch?

cheers,
  Gerd

From d46b14dfd74dcc37fe187dc76cd681ad7dbff2d5 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@redhat.com
Date: Wed, 19 Sep 2012 13:31:04 +0200
Subject: [PATCH] [fixup] vga mmio

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/vga-pci.c |   25 ++---
 1 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index e05e2ef..7fd305d 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -78,14 +78,33 @@ static uint64_t pci_vga_ioport_read(void *ptr, 
target_phys_addr_t addr,
 unsigned size)
 {
 PCIVGAState *d = ptr;
-return vga_ioport_read(d-vga, addr);
+uint64_t ret = 0;
+
+switch (size) {
+case 1:
+ret = vga_ioport_read(d-vga, addr);
+break;
+case 2:
+ret  = vga_ioport_read(d-vga, addr);
+ret |= vga_ioport_read(d-vga, addr+1)  8;
+break;
+}
+return ret;
 }
 
 static void pci_vga_ioport_write(void *ptr, target_phys_addr_t addr,
  uint64_t val, unsigned size)
 {
 PCIVGAState *d = ptr;
-vga_ioport_write(d-vga, addr, val);
+switch (size) {
+case 1:
+vga_ioport_write(d-vga, addr, val);
+break;
+case 2:
+vga_ioport_write(d-vga, addr, val  0xff);
+vga_ioport_write(d-vga, addr+1, (val  8)  0xff);
+break;
+}
 }
 
 static const MemoryRegionOps pci_vga_ioport_ops = {
@@ -94,7 +113,7 @@ static const MemoryRegionOps pci_vga_ioport_ops = {
 .valid.min_access_size = 1,
 .valid.max_access_size = 4,
 .impl.min_access_size = 1,
-.impl.max_access_size = 1,
+.impl.max_access_size = 2,
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-- 
1.7.1

Re: [Qemu-devel] [RfC PATCH] vga: add mmio bar to standard vga

[Gerd Hoffmann]

  Hi,

 +vbe_ioport_write_index(d-vga, 0, index);
 +return vbe_ioport_read_data(d-vga, 0);
 
 These functions are only available with CONFIG_BOCHS_VBE #defined, so
 this code should be conditional as well.
 
 But building without CONFIG_BOCHS_VBE is not very useful since it's
 used by the BIOS and there's no display output without it IIRC.

Well, text mode is still there, but no (by modern standards) useful
graphics modes, only standard vga ones (i.e. up to 800x600 @ 256 colors
or something like that).

I guess it is better to just remove CONFIG_BOCHS_VBE, /me goes prepare a
patch.

cheers,
  Gerd

--
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

[RfC PATCH] vga: add mmio bar to standard vga

[Gerd Hoffmann]

This patch adds a mmio bar to the qemu standard vga which allows to
access the standard vga registers and bochs dispi interface registers
via mmio.

Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/vga-pci.c |   97 ++
 hw/vga.c |6 ++--
 hw/vga_int.h |6 +++
 3 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index 9abbada..e05e2ef 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -30,9 +30,36 @@
 #include qemu-timer.h
 #include loader.h
 
+/*
+ * QEMU Standard VGA -- MMIO area spec.
+ *
+ * Using PCI bar #2, keeping #1 free, which leaves the
+ * door open to upgrade bar #0 to 64bit.
+ *
+ * mmio area layout:
+ *   0x - 0x03ff  reserved, for possible virtio extension.
+ *   0x0400 - 0x041f  vga ioports (0x3c0 - 0x3df), remapped 1:1
+ *   0x0500 - 0x0515  bochs dispi interface registers, mapped flat without
+ * index/data ports.  Use (index  1) as offset for
+ * (16bit) register access.
+ */
+#define PCI_VGA_IOPORT_OFFSET 0x400
+#define PCI_VGA_IOPORT_SIZE   (0x3e0 - 0x3c0)
+#define PCI_VGA_BOCHS_OFFSET  0x500
+#define PCI_VGA_BOCHS_SIZE(0x0b * 2)
+#define PCI_VGA_MMIO_SIZE 0x1000
+
+enum vga_pci_flags {
+PCI_VGA_FLAG_ENABLE_MMIO = 1,
+};
+
 typedef struct PCIVGAState {
 PCIDevice dev;
 VGACommonState vga;
+uint32_t flags;
+MemoryRegion mmio;
+MemoryRegion ioport;
+MemoryRegion bochs;
 } PCIVGAState;
 
 static const VMStateDescription vmstate_vga_pci = {
@@ -47,6 +74,60 @@ static const VMStateDescription vmstate_vga_pci = {
 }
 };
 
+static uint64_t pci_vga_ioport_read(void *ptr, target_phys_addr_t addr,
+unsigned size)
+{
+PCIVGAState *d = ptr;
+return vga_ioport_read(d-vga, addr);
+}
+
+static void pci_vga_ioport_write(void *ptr, target_phys_addr_t addr,
+ uint64_t val, unsigned size)
+{
+PCIVGAState *d = ptr;
+vga_ioport_write(d-vga, addr, val);
+}
+
+static const MemoryRegionOps pci_vga_ioport_ops = {
+.read = pci_vga_ioport_read,
+.write = pci_vga_ioport_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 4,
+.impl.min_access_size = 1,
+.impl.max_access_size = 1,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static uint64_t pci_vga_bochs_read(void *ptr, target_phys_addr_t addr,
+   unsigned size)
+{
+PCIVGAState *d = ptr;
+int index = addr  1;
+
+vbe_ioport_write_index(d-vga, 0, index);
+return vbe_ioport_read_data(d-vga, 0);
+}
+
+static void pci_vga_bochs_write(void *ptr, target_phys_addr_t addr,
+uint64_t val, unsigned size)
+{
+PCIVGAState *d = ptr;
+int index = addr  1;
+
+vbe_ioport_write_index(d-vga, 0, index);
+vbe_ioport_write_data(d-vga, 0, val);
+}
+
+static const MemoryRegionOps pci_vga_bochs_ops = {
+.read = pci_vga_bochs_read,
+.write = pci_vga_bochs_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 4,
+.impl.min_access_size = 2,
+.impl.max_access_size = 2,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
 static int pci_vga_initfn(PCIDevice *dev)
 {
  PCIVGAState *d = DO_UPCAST(PCIVGAState, dev, dev);
@@ -62,6 +143,21 @@ static int pci_vga_initfn(PCIDevice *dev)
  /* XXX: VGA_RAM_SIZE must be a power of two */
  pci_register_bar(d-dev, 0, PCI_BASE_ADDRESS_MEM_PREFETCH, s-vram);
 
+ /* mmio bar for vga register access */
+ if (d-flags  (1  PCI_VGA_FLAG_ENABLE_MMIO)) {
+ memory_region_init(d-mmio, vga.mmio, 4096);
+ memory_region_init_io(d-ioport, pci_vga_ioport_ops, d,
+   vga ioports remapped, PCI_VGA_IOPORT_SIZE);
+ memory_region_init_io(d-bochs, pci_vga_bochs_ops, d,
+   bochs dispi interface, PCI_VGA_BOCHS_SIZE);
+
+ memory_region_add_subregion(d-mmio, PCI_VGA_IOPORT_OFFSET,
+ d-ioport);
+ memory_region_add_subregion(d-mmio, PCI_VGA_BOCHS_OFFSET,
+ d-bochs);
+ pci_register_bar(d-dev, 2, PCI_BASE_ADDRESS_SPACE_MEMORY, d-mmio);
+ }
+
  if (!dev-rom_bar) {
  /* compatibility with pc-0.13 and older */
  vga_init_vbe(s, pci_address_space(dev));
@@ -77,6 +173,7 @@ DeviceState *pci_vga_init(PCIBus *bus)
 
 static Property vga_pci_properties[] = {
 DEFINE_PROP_UINT32(vgamem_mb, PCIVGAState, vga.vram_size_mb, 16),
+DEFINE_PROP_BIT(mmio, PCIVGAState, flags, PCI_VGA_FLAG_ENABLE_MMIO, 
true),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/vga.c b/hw/vga.c
index ec4f0c5..053f89d 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -591,7 +591,7 @@ static uint32_t vbe_ioport_read_index(void *opaque, 
uint32_t addr)
 return val;
 }
 
-static uint32_t vbe_ioport_read_data(void *opaque

Re: [RfC PATCH] vga: add mmio bar to standard vga

[Gerd Hoffmann]

On 09/18/12 12:32, Benjamin Herrenschmidt wrote:
 On Tue, 2012-09-18 at 11:51 +0200, Gerd Hoffmann wrote:
 This patch adds a mmio bar to the qemu standard vga which allows to
 access the standard vga registers and bochs dispi interface registers
 via mmio.
 
 I had a patch like that somewhere (or is that it ? :-)
 
 I dropped it in favor of a more interesting approach doing a virtio-vga,
 which Anthony and I have been hacking on a bit, but due to time
 constraints haven't really finished at this point.

Yea, has been quiet on this front for a while, thats why I looked into this.

 In any case, I'm fine with this patch but does it help anybody ?

Well, it gives you time to finish virtio-vga ;)

I have a linux kernel driver too, although not kms/drm but fbdev.

cheers,
  Gerd

--
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: graphics card pci passthrough success report

[Gerd Hoffmann]

  Hi,

 - Apply the patches at the end of this mail to kvm and SeaBIOS to
   allow for more BAR space under 4G.  (The relevant BARs on the
   graphics cards _are_ 64 bit BARs, but kvm seemed to turn those
   into 32 bit BARs in the guest.)

Which qemu/seabios versions have you used?

qemu-1.2 (+ bundled seabios) should handle that just fine without
patching.  There is no fixed I/O window any more, all memory space above
lowmem is available for pci, i.e. if you give 2G to your guest
everything above 0x8000.

And if there isn't enougth address space below 4G (if you assign lot of
memory to your guest so qemu keeps only the 0xe000 - 0x
window free) seabios should try to map 64bit bars above 4G.

 - Apply the hacky patch at the end of this mail to SeaBIOS to
   always skip initialising the Radeon's option ROMs, or the VM
   would hang inside the Radeon option ROM if you boot the VM
   without the default cirrus video.

A better way to handle that would probably be to add an pci passthrough
config option to not expose the rom to the guest.

Any clue *why* the rom doesn't run?

cheers,
  Gerd
--
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

[Gerd Hoffmann]

On 09/06/12 01:28, Kevin O'Connor wrote:
 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?

Oops.  Change was still uncommitted in my work tree, /me just forgot
'git add' I guess.  New version on the way.

cheers,
  Gerd

--
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] add acpi pmtimer support

[Gerd Hoffmann]

  Hi,

 +u32 pmtimer = inl(ioport);
 +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 ?
 The pmtimer is defined to be 24 bits wide, so the shift is correct.
 This is not true in general.  It can be either 24 or 32 bits.  What it
 is depends on ACPI data (acpi_gbl_FADT-tmr_val_ext).

The piix4 emulated by qemu has 24 bits.

  However it is
 valid to only used 24 bits.

And we certainly want to mask the ioport read (as suggested by kevin and
done in v3 of the patch) so we only pick up the 24 bits we actually use.

thanks
  Gerd

--
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

[Gerd Hoffmann]

On 09/02/12 22:42, Kevin O'Connor wrote:
 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.)

It is still a good idea to make timing in a virtual machine more robust.

 +u32 pmtimer = inl(ioport);

 +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 ?

The pmtimer is defined to be 24 bits wide, so the shift is correct.
But, yes, the ioport read should better be masked to be on the safe
side.  v3 will go out in a minute.

cheers,
  Gerd
--
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

[PATCH v3] add acpi pmtimer support

[Gerd Hoffmann]

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 ]
[ v2: add CONFIG_PMTIMER ]

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/Kconfig   |6 ++
 src/clock.c   |   31 +++
 src/pciinit.c |5 +
 src/util.h|1 +
 4 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 6de3e71..b5dd63b 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -222,6 +222,12 @@ menu Hardware support
 default y
 help
 Initialize the Memory Type Range Registers (on emulators).
+config PMTIMER
+depends on !COREBOOT
+bool Use ACPI timer
+default y
+help
+Use the ACPI timer instead of the TSC for timekeeping (on qemu).
 endmenu
 
 menu BIOS interfaces
diff --git a/src/clock.c b/src/clock.c
index 69e9f17..b4abf37 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -129,11 +129,42 @@ emulate_tsc(void)
 return ret;
 }
 
+u16 pmtimer_ioport VAR16VISIBLE;
+u32 pmtimer_wraps VARLOW;
+u32 pmtimer_last VARLOW;
+
+void pmtimer_init(u16 ioport, u32 khz)
+{
+if (!CONFIG_PMTIMER)
+return;
+dprintf(1, Using pmtimer, ioport 0x%x, freq %d kHz\n, ioport, khz);
+SET_GLOBAL(pmtimer_ioport, ioport);
+SET_GLOBAL(cpu_khz, khz);
+}
+
+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;
+}
+
 static u64
 get_tsc(void)
 {
 if (unlikely(GET_GLOBAL(no_tsc)))
 return emulate_tsc();
+if (CONFIG_PMTIMER  GET_GLOBAL(pmtimer_ioport))
+return pmtimer_get();
 return rdtscll();
 }
 
diff --git a/src/pciinit.c b/src/pciinit.c
index 68f302a..31115ee 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -180,6 +180,9 @@ static const struct pci_device_id pci_class_tbl[] = {
 PCI_DEVICE_END,
 };
 
+/* PM Timer ticks per second (HZ) */
+#define PM_TIMER_FREQUENCY  3579545
+
 /* PIIX4 Power Management device (for ACPI) */
 static void piix4_pm_init(struct pci_device *pci, void *arg)
 {
@@ -191,6 +194,8 @@ static void piix4_pm_init(struct pci_device *pci, void *arg)
 pci_config_writeb(bdf, 0x80, 0x01); /* enable PM io space */
 pci_config_writel(bdf, 0x90, PORT_SMB_BASE | 1);
 pci_config_writeb(bdf, 0xd2, 0x09); /* enable SMBus io space */
+
+pmtimer_init(PORT_ACPI_PM_BASE + 0x08, PM_TIMER_FREQUENCY / 1000);
 }
 
 static const struct pci_device_id pci_device_tbl[] = {
diff --git a/src/util.h b/src/util.h
index 062eea3..7723bb1 100644
--- a/src/util.h
+++ b/src/util.h
@@ -282,6 +282,7 @@ void lpt_setup(void);
 // clock.c
 #define PIT_TICK_RATE 1193180   // Underlying HZ of PIT
 #define PIT_TICK_INTERVAL 65536 // Default interval for 18.2Hz timer
+void pmtimer_init(u16 ioport, u32 khz);
 int check_tsc(u64 end);
 void timer_setup(void);
 void ndelay(u32 count);
-- 
1.7.1

--
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] tsc: use kvmclock for calibration

[Gerd Hoffmann]

  Hi,

 Isnt pmtimer ioport usable? 14MHz.

Can give it a try.  14 MHz looks wrong though, apci.h says:

/* PM Timer ticks per second (HZ) */
#define PM_TIMER_FREQUENCY  3579545

Is this fixed?  Or hardware specific?

cheers,
  Gerd

--
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

[PATCH] add acpi pmtimer support

[Gerd Hoffmann]

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.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/clock.c   |   29 +
 src/pciinit.c |5 +
 src/util.h|1 +
 3 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/src/clock.c b/src/clock.c
index 69e9f17..59f269b 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -129,11 +129,40 @@ emulate_tsc(void)
 return ret;
 }
 
+u16 pmtimer_ioport VAR16VISIBLE;
+u32 pmtimer_wraps VARLOW;
+u32 pmtimer_last VARLOW;
+
+void pmtimer_init(u16 ioport, u32 khz)
+{
+dprintf(1, Using pmtimer, ioport 0x%x, freq %d kHz\n, ioport, khz);
+SET_GLOBAL(pmtimer_ioport, ioport);
+SET_GLOBAL(cpu_khz, khz);
+}
+
+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;
+}
+
 static u64
 get_tsc(void)
 {
 if (unlikely(GET_GLOBAL(no_tsc)))
 return emulate_tsc();
+if (GET_GLOBAL(pmtimer_ioport))
+return pmtimer_get();
 return rdtscll();
 }
 
diff --git a/src/pciinit.c b/src/pciinit.c
index 68f302a..31115ee 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -180,6 +180,9 @@ static const struct pci_device_id pci_class_tbl[] = {
 PCI_DEVICE_END,
 };
 
+/* PM Timer ticks per second (HZ) */
+#define PM_TIMER_FREQUENCY  3579545
+
 /* PIIX4 Power Management device (for ACPI) */
 static void piix4_pm_init(struct pci_device *pci, void *arg)
 {
@@ -191,6 +194,8 @@ static void piix4_pm_init(struct pci_device *pci, void *arg)
 pci_config_writeb(bdf, 0x80, 0x01); /* enable PM io space */
 pci_config_writel(bdf, 0x90, PORT_SMB_BASE | 1);
 pci_config_writeb(bdf, 0xd2, 0x09); /* enable SMBus io space */
+
+pmtimer_init(PORT_ACPI_PM_BASE + 0x08, PM_TIMER_FREQUENCY / 1000);
 }
 
 static const struct pci_device_id pci_device_tbl[] = {
diff --git a/src/util.h b/src/util.h
index 89e928c..1603a57 100644
--- a/src/util.h
+++ b/src/util.h
@@ -312,6 +312,7 @@ void lpt_setup(void);
 // clock.c
 #define PIT_TICK_RATE 1193180   // Underlying HZ of PIT
 #define PIT_TICK_INTERVAL 65536 // Default interval for 18.2Hz timer
+void pmtimer_init(u16 ioport, u32 khz);
 int check_tsc(u64 end);
 void timer_setup(void);
 void ndelay(u32 count);
-- 
1.7.1

--
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

[PATCH v2] add acpi pmtimer support

[Gerd Hoffmann]

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.

[ v2: add CONFIG_PMTIMER ]

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/Kconfig   |6 ++
 src/clock.c   |   31 +++
 src/pciinit.c |5 +
 src/util.h|1 +
 4 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/src/Kconfig b/src/Kconfig
index 6de3e71..b5dd63b 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -222,6 +222,12 @@ menu Hardware support
 default y
 help
 Initialize the Memory Type Range Registers (on emulators).
+config PMTIMER
+depends on !COREBOOT
+bool Use ACPI timer
+default y
+help
+Use the ACPI timer instead of the TSC for timekeeping (on qemu).
 endmenu
 
 menu BIOS interfaces
diff --git a/src/clock.c b/src/clock.c
index 69e9f17..b4abf37 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -129,11 +129,42 @@ emulate_tsc(void)
 return ret;
 }
 
+u16 pmtimer_ioport VAR16VISIBLE;
+u32 pmtimer_wraps VARLOW;
+u32 pmtimer_last VARLOW;
+
+void pmtimer_init(u16 ioport, u32 khz)
+{
+if (!CONFIG_PMTIMER)
+return;
+dprintf(1, Using pmtimer, ioport 0x%x, freq %d kHz\n, ioport, khz);
+SET_GLOBAL(pmtimer_ioport, ioport);
+SET_GLOBAL(cpu_khz, khz);
+}
+
+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;
+}
+
 static u64
 get_tsc(void)
 {
 if (unlikely(GET_GLOBAL(no_tsc)))
 return emulate_tsc();
+if (CONFIG_PMTIMER  GET_GLOBAL(pmtimer_ioport))
+return pmtimer_get();
 return rdtscll();
 }
 
diff --git a/src/pciinit.c b/src/pciinit.c
index 68f302a..31115ee 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -180,6 +180,9 @@ static const struct pci_device_id pci_class_tbl[] = {
 PCI_DEVICE_END,
 };
 
+/* PM Timer ticks per second (HZ) */
+#define PM_TIMER_FREQUENCY  3579545
+
 /* PIIX4 Power Management device (for ACPI) */
 static void piix4_pm_init(struct pci_device *pci, void *arg)
 {
@@ -191,6 +194,8 @@ static void piix4_pm_init(struct pci_device *pci, void *arg)
 pci_config_writeb(bdf, 0x80, 0x01); /* enable PM io space */
 pci_config_writel(bdf, 0x90, PORT_SMB_BASE | 1);
 pci_config_writeb(bdf, 0xd2, 0x09); /* enable SMBus io space */
+
+pmtimer_init(PORT_ACPI_PM_BASE + 0x08, PM_TIMER_FREQUENCY / 1000);
 }
 
 static const struct pci_device_id pci_device_tbl[] = {
diff --git a/src/util.h b/src/util.h
index 89e928c..1603a57 100644
--- a/src/util.h
+++ b/src/util.h
@@ -312,6 +312,7 @@ void lpt_setup(void);
 // clock.c
 #define PIT_TICK_RATE 1193180   // Underlying HZ of PIT
 #define PIT_TICK_INTERVAL 65536 // Default interval for 18.2Hz timer
+void pmtimer_init(u16 ioport, u32 khz);
 int check_tsc(u64 end);
 void timer_setup(void);
 void ndelay(u32 count);
-- 
1.7.1

--
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] tsc: use kvmclock for calibration

[Gerd Hoffmann]

  Hi,

   (1) Use this patch (with alignment issue fixed of course).
   (2) Do a full kvmclock implementation.  Feels a bit like overkill.
   (3) SeaBIOS can fallback to the PIT for timing on machines which
   have no TSC.  We could do that too in case we detect kvm ...

 What sort of timeouts are these?  If seconds, maybe the rtc would be best.
 
 I vote for 3 so nobody has to maintain kvmclock code in SeaBIOS and Gerd
 can fix the in-kernel PIT issues with GRUB (see Michaels message) while 
 testing.

(2) turned out to be not too bad when taking a shortcut: Go through an
enable/disable cycle each time we read the clock, then just grab
system_time.  Not that efficient, but should be ok for seabios.  Usually
it checks the clock when sitting around idle, waiting for something to
happen.  And it simplifies the implementation alot as we can just skip
all the tsc frequency  delta calculations.

Draft patch attached.  Comments?

cheers,
  Gerd
From e42d62e90ae4b8a00413a0665d4022069154a516 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@redhat.com
Date: Thu, 9 Aug 2012 13:26:18 +0200
Subject: [PATCH] kvmclock clocksource

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 Makefile   |4 +-
 src/clock.c|   13 +++
 src/paravirt.c |   65 
 src/paravirt.h |3 ++
 4 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 72ee152..b692a96 100644
--- a/Makefile
+++ b/Makefile
@@ -13,11 +13,11 @@ SRCBOTH=misc.c stacks.c pmm.c output.c util.c block.c 
floppy.c ata.c mouse.c \
 pnpbios.c pirtable.c vgahooks.c ramdisk.c pcibios.c blockcmd.c \
 usb.c usb-uhci.c usb-ohci.c usb-ehci.c usb-hid.c usb-msc.c \
 virtio-ring.c virtio-pci.c virtio-blk.c virtio-scsi.c apm.c ahci.c \
-usb-uas.c lsi-scsi.c esp-scsi.c
+usb-uas.c lsi-scsi.c esp-scsi.c paravirt.c
 SRC16=$(SRCBOTH) system.c disk.c font.c
 SRC32FLAT=$(SRCBOTH) post.c shadow.c memmap.c coreboot.c boot.c \
 acpi.c smm.c mptable.c smbios.c pciinit.c optionroms.c mtrr.c \
-lzmadecode.c bootsplash.c jpeg.c usb-hub.c paravirt.c \
+lzmadecode.c bootsplash.c jpeg.c usb-hub.c \
 biostables.c xen.c bmp.c romfile.c
 SRC32SEG=util.c output.c pci.c pcibios.c apm.c stacks.c
 
diff --git a/src/clock.c b/src/clock.c
index 69e9f17..15921fa 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -13,6 +13,7 @@
 #include bregs.h // struct bregs
 #include biosvar.h // GET_GLOBAL
 #include usb-hid.h // usb_check_event
+#include paravirt.h // kvm clock
 
 // RTC register flags
 #define RTC_A_UIP 0x80
@@ -64,6 +65,7 @@
 
 u32 cpu_khz VAR16VISIBLE;
 u8 no_tsc VAR16VISIBLE;
+u8 use_kvmclock VAR16VISIBLE;
 
 static void
 calibrate_tsc(void)
@@ -80,6 +82,15 @@ calibrate_tsc(void)
 return;
 }
 
+if (kvm_para_available()) {
+u32 hz = kvmclock_init();
+if (hz != 0) {
+SET_GLOBAL(use_kvmclock, 1);
+SET_GLOBAL(cpu_khz, hz / 1000);
+return;
+}
+}
+
 // Setup timer2
 u8 orig = inb(PORT_PS2_CTRLB);
 outb((orig  ~PPCB_SPKR) | PPCB_T2GATE, PORT_PS2_CTRLB);
@@ -134,6 +145,8 @@ get_tsc(void)
 {
 if (unlikely(GET_GLOBAL(no_tsc)))
 return emulate_tsc();
+if (unlikely(GET_GLOBAL(use_kvmclock)))
+return kvmclock_get();
 return rdtscll();
 }
 
diff --git a/src/paravirt.c b/src/paravirt.c
index 2a98d53..07aa926 100644
--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -12,6 +12,7 @@
 #include ioport.h // outw
 #include paravirt.h // qemu_cfg_port_probe
 #include smbios.h // struct smbios_structure_header
+#include biosvar.h // GET_GLOBAL
 
 int qemu_cfg_present;
 
@@ -346,3 +347,67 @@ void qemu_cfg_romfile_setup(void)
 dprintf(3, Found fw_cfg file: %s (size=%d)\n, file-name, 
file-size);
 }
 }
+
+#define KVM_CPUID_SIGNATURE   0x4000
+#define KVM_CPUID_FEATURES0x4001
+#define KVM_FEATURE_CLOCKSOURCE0
+#define KVM_FEATURE_CLOCKSOURCE2   3
+#define MSR_KVM_SYSTEM_TIME 0x12
+#define MSR_KVM_SYSTEM_TIME_NEW   0x4b564d01
+
+struct pvclock_vcpu_time_info {
+   u32   version;
+   u32   pad0;
+   u64   tsc_timestamp;
+   u64   system_time;
+   u32   tsc_to_system_mul;
+   s8tsc_shift;
+   u8flags;
+   u8pad[2];
+} PACKED;
+
+/* kvmclock system time runs with nanoseconds */
+#define KVM_SYSTIME_HZ   10
+
+u32 kvm_systime_msr VAR16VISIBLE;
+
+static void kvmclock_fetch(struct pvclock_vcpu_time_info *time)
+{
+u32 addr = (u32)MAKE_FLATPTR(GET_SEG(SS), time);
+u32 msr = GET_GLOBAL(kvm_systime_msr);
+
+memset(time, 0, sizeof(*time));
+wrmsr(msr, addr | 1);
+wrmsr(msr, 0);
+}
+
+u64 kvmclock_get(void)
+{
+struct pvclock_vcpu_time_info time;
+
+kvmclock_fetch(time);
+return time.system_time;
+}
+
+u32 kvmclock_init(void)
+{
+u32 eax, ebx, ecx, edx;
+struct pvclock_vcpu_time_info time;
+
+cpuid(KVM_CPUID_FEATURES, eax, ebx

[PATCH] tsc: use kvmclock for calibration

[Gerd Hoffmann]

Use kvmclock for tsc calibration when running on kvm.  Without this the
tsc frequency calibrated by seabios can be *way* off in case the virtual
machine is booted on a loaded host.  I've seen seabios calibrating 27
instead of ca. 2800 MHz, resulting in timeouts being to short by factor
100.  Which in turn leads to disk I/O errors due to timeouts, especially
as I/O requests tend to take a bit longer than usual on a loaded box ...

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 src/clock.c|9 +
 src/paravirt.c |   90 
 src/paravirt.h |1 +
 3 files changed, 100 insertions(+), 0 deletions(-)

diff --git a/src/clock.c b/src/clock.c
index 69e9f17..5883b1a 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -13,6 +13,7 @@
 #include bregs.h // struct bregs
 #include biosvar.h // GET_GLOBAL
 #include usb-hid.h // usb_check_event
+#include paravirt.h // kvm clock
 
 // RTC register flags
 #define RTC_A_UIP 0x80
@@ -80,6 +81,14 @@ calibrate_tsc(void)
 return;
 }
 
+if (kvm_para_available()) {
+u32 khz = kvm_tsc_khz();
+if (khz != 0) {
+SET_GLOBAL(cpu_khz, khz);
+return;
+}
+}
+
 // Setup timer2
 u8 orig = inb(PORT_PS2_CTRLB);
 outb((orig  ~PPCB_SPKR) | PPCB_T2GATE, PORT_PS2_CTRLB);
diff --git a/src/paravirt.c b/src/paravirt.c
index 2a98d53..942ce11 100644
--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -12,6 +12,7 @@
 #include ioport.h // outw
 #include paravirt.h // qemu_cfg_port_probe
 #include smbios.h // struct smbios_structure_header
+#include biosvar.h // GET_GLOBAL
 
 int qemu_cfg_present;
 
@@ -346,3 +347,92 @@ void qemu_cfg_romfile_setup(void)
 dprintf(3, Found fw_cfg file: %s (size=%d)\n, file-name, 
file-size);
 }
 }
+
+#define KVM_CPUID_SIGNATURE   0x4000
+#define KVM_CPUID_FEATURES0x4001
+#define KVM_FEATURE_CLOCKSOURCE0
+#define KVM_FEATURE_CLOCKSOURCE2   3
+#define MSR_KVM_SYSTEM_TIME 0x12
+#define MSR_KVM_SYSTEM_TIME_NEW   0x4b564d01
+
+struct pvclock_vcpu_time_info {
+   u32   version;
+   u32   pad0;
+   u64   tsc_timestamp;
+   u64   system_time;
+   u32   tsc_to_system_mul;
+   s8tsc_shift;
+   u8flags;
+   u8pad[2];
+} PACKED;
+
+/*
+ * do_div() is NOT a C function. It wants to return
+ * two values (the quotient and the remainder), but
+ * since that doesn't work very well in C, what it
+ * does is:
+ *
+ * - modifies the 64-bit dividend _in_place_
+ * - returns the 32-bit remainder
+ *
+ * This ends up being the most efficient calling
+ * convention on x86.
+ */
+#define do_div(n, base) \
+({  \
+unsigned long __upper, __low, __high, __mod, __base;\
+__base = (base);\
+asm( : =a (__low), =d (__high) : A (n));\
+__upper = __high;   \
+if (__high) {   \
+__upper = __high % (__base);\
+__high = __high / (__base); \
+}   \
+asm(divl %2 : =a (__low), =d (__mod)  \
+: rm (__base), 0 (__low), 1 (__upper));   \
+asm( : =A (n) : a (__low), d (__high)); \
+__mod;  \
+})
+
+static u64 pvclock_tsc_khz(struct pvclock_vcpu_time_info *src)
+{
+u64 pv_tsc_khz = 100ULL  32;
+
+do_div(pv_tsc_khz, src-tsc_to_system_mul);
+if (src-tsc_shift  0)
+pv_tsc_khz = -src-tsc_shift;
+else
+pv_tsc_khz = src-tsc_shift;
+return pv_tsc_khz;
+}
+
+u64 kvm_tsc_khz(void)
+{
+u32 eax, ebx, ecx, edx, msr;
+struct pvclock_vcpu_time_info time;
+u32 addr = (u32)(time);
+u64 khz;
+
+/* check presence and figure msr number */
+cpuid(KVM_CPUID_FEATURES, eax, ebx, ecx, edx);
+if (eax  KVM_FEATURE_CLOCKSOURCE2) {
+msr = MSR_KVM_SYSTEM_TIME_NEW;
+} else if (eax  KVM_FEATURE_CLOCKSOURCE) {
+msr = MSR_KVM_SYSTEM_TIME;
+} else {
+return 0;
+}
+
+/* ask kvm hypervisor to fill struct */
+memset(time, 0, sizeof(time));
+wrmsr(msr, addr | 1);
+wrmsr(msr, 0);
+if (time.version  2 || time.tsc_to_system_mul == 0)
+return 0;
+
+/* go figure tsc frequency */
+khz = pvclock_tsc_khz(time);
+dprintf(1, Using kvmclock, msr 0x%x, tsc %d MHz\n,
+msr, (u32)khz / 1000);
+return khz;
+}
diff --git a/src/paravirt.h b/src/paravirt.h
index a284c41..eedfcc3 100644
--- a/src/paravirt.h
+++ b/src/paravirt.h
@@ -27,6 +27,7 @@ static inline int

Re: [PATCH] tsc: use kvmclock for calibration

[Gerd Hoffmann]

  Hi,

 +u64 kvm_tsc_khz(void)
 +{
 +u32 eax, ebx, ecx, edx, msr;
 +struct pvclock_vcpu_time_info time;
 +u32 addr = (u32)(time);
 +u64 khz;
 +
 +/* check presence and figure msr number */
 +cpuid(KVM_CPUID_FEATURES, eax, ebx, ecx, edx);
 +if (eax  KVM_FEATURE_CLOCKSOURCE2) {
 +msr = MSR_KVM_SYSTEM_TIME_NEW;
 +} else if (eax  KVM_FEATURE_CLOCKSOURCE) {
 +msr = MSR_KVM_SYSTEM_TIME;
 +} else {
 +return 0;
 +}
 +
 +/* ask kvm hypervisor to fill struct */
 +memset(time, 0, sizeof(time));
 +wrmsr(msr, addr | 1);
 
 How can this work?

It did in my testing, although maybe by pure luck ...

 There is a 64-byte alignment requirement.

64 bytes?  Sure?  The whole struct is only 32 bytes in size ...

Easily fixable though, just need to grab some memory with memalign
instead of using the stack.

 +wrmsr(msr, 0);
 +if (time.version  2 || time.tsc_to_system_mul == 0)
 +return 0;
 +
 +/* go figure tsc frequency */
 +khz = pvclock_tsc_khz(time);
 +dprintf(1, Using kvmclock, msr 0x%x, tsc %d MHz\n,
 +msr, (u32)khz / 1000);
 +return khz;
 
 That's a meaningless number.  You can be migrated to a cpu or a machine
 with very different tsc.

 You want accurate time on kvm, don't use the tsc.

seabios uses the tsc for timeout calculations only, so it doesn't need
to be 100% accurate.  The order of magnitude should be correct though.
The Linux kernel uses the value for delay loops too, so using it for the
given purpose can't be *that* horrible after all ...

It is certainly an improvement over the current code which tries to
calibrate the tsc and gets totally broken results in case the busy host
happens to schedule the guest in the middle of calibration.

So what do you suggest?  The options I see are:

  (1) Use this patch (with alignment issue fixed of course).
  (2) Do a full kvmclock implementation.  Feels a bit like overkill.
  (3) SeaBIOS can fallback to the PIT for timing on machines which
  have no TSC.  We could do that too in case we detect kvm ...

cheers,
  Gerd
--
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] tsc: use kvmclock for calibration

[Gerd Hoffmann]

  Hi,

 er, the documentation says 4 bytes (so stack alignment works).  I
 distinctly remember having a large alignment requirement so we don't
 cross a page or slot boundary... something's wrong here.
 
   case MSR_KVM_SYSTEM_TIME: {
[ ... ]

 So your tests worked by pure luck, but the bug is in kvm.  We need to
 grab two pages here.

Ok, so better use memalign(32,32) to make sure the struct doesn't cross
a page border ...

cheers,
  Gerd
--
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] tsc: use kvmclock for calibration

[Gerd Hoffmann]

  Hi,

 So what do you suggest?  The options I see are:

   (1) Use this patch (with alignment issue fixed of course).
   (2) Do a full kvmclock implementation.  Feels a bit like overkill.
   (3) SeaBIOS can fallback to the PIT for timing on machines which
   have no TSC.  We could do that too in case we detect kvm ...
 
 What sort of timeouts are these?  If seconds, maybe the rtc would be best.

All sorts of timeouts, from a few miliseconds to seconds.

The problematic ones are the longer timeouts, which wait for I/O stuff
like disk reads complete.  The stuff with smaller timeouts (like waiting
for AHCI link become ready) tend to finish instantly in kvm.

cheers,
  Gerd
--
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 v2 05/21][SeaBIOS] pciinit: Fix pcimem_start value

[Gerd Hoffmann]

On 07/11/12 18:45, Vasilis Liaskovitis wrote:
 Hi,
 
 On Wed, Jul 11, 2012 at 01:56:19PM +0200, Gerd Hoffmann wrote:
 On 07/11/12 12:31, Vasilis Liaskovitis wrote:
 In order to hotplug memory between RamSize and BUILD_PCIMEM_START, the pci
 window needs to start at BUILD_PCIMEM_START (0xe000).
 Otherwise, the guest cannot online new dimms at those ranges due to pci_root
 window conflicts. (workaround for linux guest is booting with pci=nocrs)

  static void pci_bios_map_devices(struct pci_bus *busses)
  {
 -pcimem_start = RamSize;
 +pcimem_start = BUILD_PCIMEM_START;

 It isn't that simple.  For the 32bit pci window it will work, but will
 leaves address space unused instead of assigning it to the 32bit pci
 window.  For the 64bit pci window it will not work.

 You have to walk the dimms and figure what the highest used address is,
 for both below-4g and above-4g.  Then fill two variable with it and make
 the pci init code use that instead of RamSize and RamSizeOver4G.
 
 I see. I already have these values values computed in qemu-kvm, so I can pass
 them in a paravirt struct, or infer them from the dimm/srat paravirt info 
 that I
 already pass to seabios. 

I'd suggest to infer from the dimm info, to limit the amout of
information which needs to be passed from qemu to seabios.

 If i understand correctly, we would like the pcimem windows to use the maximum
 possible address space (constrained by the exact dimms/ranges which are 
 defined)
 instead of leaving unused space.

Yes, for the 32bit pci window.

The 64bit pci window is mapped above all memory, and it must likewise
consider defined+unfilled dimms so the start address doesn't collide
with memory hot-plugged above 4G later on.

cheers,
  Gerd

--
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 v2 05/21][SeaBIOS] pciinit: Fix pcimem_start value

[Gerd Hoffmann]

On 07/11/12 12:31, Vasilis Liaskovitis wrote:
 In order to hotplug memory between RamSize and BUILD_PCIMEM_START, the pci
 window needs to start at BUILD_PCIMEM_START (0xe000).
 Otherwise, the guest cannot online new dimms at those ranges due to pci_root
 window conflicts. (workaround for linux guest is booting with pci=nocrs)

  static void pci_bios_map_devices(struct pci_bus *busses)
  {
 -pcimem_start = RamSize;
 +pcimem_start = BUILD_PCIMEM_START;

It isn't that simple.  For the 32bit pci window it will work, but will
leaves address space unused instead of assigning it to the 32bit pci
window.  For the 64bit pci window it will not work.

You have to walk the dimms and figure what the highest used address is,
for both below-4g and above-4g.  Then fill two variable with it and make
the pci init code use that instead of RamSize and RamSizeOver4G.

cheers,
  Gerd
--
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] ehci: Kick async schedule on wakeup in the non companion case

[Gerd Hoffmann]

On 07/06/12 16:53, Hans de Goede wrote:
 Commit 0f588df8b3688b00e77aabaa32e26ece5f19bd39, added code
 to ehci_wakeup to kick the async schedule on wakeup, but the else
 was positioned wrong making it trigger for devices which are routed
 to the companion rather then to the ehci controller itself.
 
 This patch fixes this. Note that the programming style with using the
 return at the end of the companion block matches how the companion case
 is handled in the other ports ops, and is done this way for consistency.

Added to usb patch queue.

thanks,
  Gerd

--
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: 2 bug-fixes, for master *and* for stable-1.1

[Gerd Hoffmann]

On 07/06/12 12:09, Hans de Goede wrote:
 Here are USB 2 bug-fixes, please also cherry-pick these into the
 stable-1.1 branch, esp. the second one as that fixes an easily triggerable
 assert.
 
 Note these patches are against 1.1.0, not against master, but they are 
 relevant
 for, and should apply to, master too.

Looks good, queued up for master.

cheers,
  Gerd

--
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

qemu xhci mini howto (was: Re: [Qemu-devel] [ANNOUNCE] qemu-kvm-1.1-rc3)

[Gerd Hoffmann]

On 05/28/12 11:30, Avi Kivity wrote:
 On 05/25/2012 11:36 AM, Veruca Salt wrote:

 Avi- would love to test out 1.1, as we are currently using the ehci method
  which has been frozen at 'experimental' for so long.

 Is there any user documentation on the xhci methods?
 
 Copying qemu-devel, where someone may know the answer.

There are no docs.  But xhci can handle all devices by itself, no need
to do all this companion controller stuff you have to do with ehci for
usb 1.1 compatibility.  Thus it's pretty simple actually:


(1) You add the xhci host adapter:

qemu $args -device nec-usb-xhci,id=xhci

(2) You add usb devices devices as usual:

qemu $args -device usb-tablet,bus=xhci.0

(3) There is no third step ;)


Advantages of xhci:
 * higher performance, less cpu overhead (thanks to the
   virtualization/emulation friendly hardware design).

Known issues (for qemu 1.1, list hopefully becomes shorter for 1.2):
 * Got less testing than ehci.
 * No usb-hub support yet (i.e. you are limited to the 4 root ports,
   but as the qemu-emulated usb hub supports usb 1.1 only you probably
   want avoid it anyway ...).
 * No usb 3.0 ports yet.
 * No isochronous transfer support yet.
 * No seabios support yet (i.e. you can't boot from xhci-connected
   usbsticks).

cheers,
  Gerd
--
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

[RfC PATCH 0/2] vga: make ram size configurable

[Gerd Hoffmann]

  Hi,

This is part of the plan to vanish the remaining differences between
qemu and qemu-kvm.  qemu has 8 MB vram, whereas qemu-kvm has 16 MB.

Making it configurable allows to keep qemu's default for compatibility
reasons while satisfying qemu-kvm users too.  Also adds new options like
reducing video memory (1 MB is minimum) for textmode-only guests or qemu
scalability tests.

Comments?

cheers,
  Gerd

Gerd Hoffmann (2):
  vga: raise xres+yres limits
  vga: make vram size configurable

 hw/cirrus_vga.c |8 ++--
 hw/qxl.c|5 -
 hw/vga-isa.c|8 +++-
 hw/vga-pci.c|8 +++-
 hw/vga.c|   13 ++---
 hw/vga_int.h|8 
 hw/vmware_vga.c |   13 ++---
 7 files changed, 48 insertions(+), 15 deletions(-)

--
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

[RfC PATCH 1/2] vga: raise xres+yres limits

[Gerd Hoffmann]

The vgabios will check whenever any given video mode will fit into the
given video memory before adding it to the list of available modes, so
there is no need to keep xmax * ymax * 32bpp lower than VGA_RAM_SIZE.

Lets raise the limits a bit.  Should be good for a few years, display
sizes are not growing that fast.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/vga_int.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/vga_int.h b/hw/vga_int.h
index 7685b2b..297c2f1 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -31,8 +31,8 @@
 /* bochs VBE support */
 #define CONFIG_BOCHS_VBE
 
-#define VBE_DISPI_MAX_XRES  1600
-#define VBE_DISPI_MAX_YRES  1200
+#define VBE_DISPI_MAX_XRES  16000
+#define VBE_DISPI_MAX_YRES  12000
 #define VBE_DISPI_MAX_BPP   32
 
 #define VBE_DISPI_INDEX_ID  0x0
-- 
1.7.1

--
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

[RfC PATCH 2/2] vga: make vram size configurable

[Gerd Hoffmann]

Zap the global VGA_RAM_SIZE #define, make the vga ram size configurable
for standard vga and vmware vga.  cirrus and qxl are left with a fixed
size (and private VGA_RAM_SIZE #define) for now.

qxl needs some non-trivial adjustments in the mode list handling deal
with a runtime-configurable size, which calls for a separate qxl patch.

cirrus emulates cards which have 2 MB (isa) and 4 MB (pci), so I guess
it would make sense to use these sizes.  That change would break
migration though, so I left it fixed at 8 MB size.  Making it
configurabls is pretty pointless for cirrus as we have to match real
hardware.

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/cirrus_vga.c |8 ++--
 hw/qxl.c|5 -
 hw/vga-isa.c|8 +++-
 hw/vga-pci.c|8 +++-
 hw/vga.c|   13 ++---
 hw/vga_int.h|4 ++--
 hw/vmware_vga.c |   13 ++---
 7 files changed, 46 insertions(+), 13 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index afedaa4..623dd68 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -43,6 +43,8 @@
 //#define DEBUG_CIRRUS
 //#define DEBUG_BITBLT
 
+#define VGA_RAM_SIZE (8192 * 1024)
+
 /***
  *
  *  definitions
@@ -2891,7 +2893,8 @@ static int vga_initfn(ISADevice *dev)
 ISACirrusVGAState *d = DO_UPCAST(ISACirrusVGAState, dev, dev);
 VGACommonState *s = d-cirrus_vga.vga;
 
-vga_common_init(s, VGA_RAM_SIZE);
+s-vram_size_mb = VGA_RAM_SIZE  20;
+vga_common_init(s);
 cirrus_init_common(d-cirrus_vga, CIRRUS_ID_CLGD5430, 0,
isa_address_space(dev));
 s-ds = graphic_console_init(s-update, s-invalidate,
@@ -2933,7 +2936,8 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
  int16_t device_id = pc-device_id;
 
  /* setup VGA */
- vga_common_init(s-vga, VGA_RAM_SIZE);
+ s-vga.vram_size_mb = VGA_RAM_SIZE  20;
+ vga_common_init(s-vga);
  cirrus_init_common(s, device_id, 1, pci_address_space(dev));
  s-vga.ds = graphic_console_init(s-vga.update, s-vga.invalidate,
   s-vga.screen_dump, s-vga.text_update,
diff --git a/hw/qxl.c b/hw/qxl.c
index 3da3399..9a32f14 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -27,6 +27,8 @@
 
 #include qxl.h
 
+#define VGA_RAM_SIZE (8192 * 1024)
+
 /*
  * NOTE: SPICE_RING_PROD_ITEM accesses memory on the pci bar and as
  * such can be changed by the guest, so to avoid a guest trigerrable
@@ -1835,7 +1837,8 @@ static int qxl_init_primary(PCIDevice *dev)
 
 qxl-id = 0;
 qxl_init_ramsize(qxl, 32);
-vga_common_init(vga, qxl-vga.vram_size);
+vga-vram_size_mb = qxl-vga.vram_size  20;
+vga_common_init(vga);
 vga_init(vga, pci_address_space(dev), pci_address_space_io(dev), false);
 portio_list_init(qxl_vga_port_list, qxl_vga_portio_list, vga, vga);
 portio_list_add(qxl_vga_port_list, pci_address_space_io(dev), 0x3b0);
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index 4bcc4db..d290473 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -49,7 +49,7 @@ static int vga_initfn(ISADevice *dev)
 MemoryRegion *vga_io_memory;
 const MemoryRegionPortio *vga_ports, *vbe_ports;
 
-vga_common_init(s, VGA_RAM_SIZE);
+vga_common_init(s);
 s-legacy_address_space = isa_address_space(dev);
 vga_io_memory = vga_init_io(s, vga_ports, vbe_ports);
 isa_register_portio_list(dev, 0x3b0, vga_ports, s, vga);
@@ -69,6 +69,11 @@ static int vga_initfn(ISADevice *dev)
 return 0;
 }
 
+static Property vga_isa_properties[] = {
+DEFINE_PROP_UINT32(vgamem_mb, ISAVGAState, state.vram_size_mb, 8),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void vga_class_initfn(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -76,6 +81,7 @@ static void vga_class_initfn(ObjectClass *klass, void *data)
 ic-init = vga_initfn;
 dc-reset = vga_reset_isa;
 dc-vmsd = vmstate_vga_common;
+dc-props = vga_isa_properties;
 }
 
 static TypeInfo vga_info = {
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index 465b643..0848126 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -53,7 +53,7 @@ static int pci_vga_initfn(PCIDevice *dev)
  VGACommonState *s = d-vga;
 
  // vga + console init
- vga_common_init(s, VGA_RAM_SIZE);
+ vga_common_init(s);
  vga_init(s, pci_address_space(dev), pci_address_space_io(dev), true);
 
  s-ds = graphic_console_init(s-update, s-invalidate,
@@ -75,6 +75,11 @@ DeviceState *pci_vga_init(PCIBus *bus)
 return pci_create_simple(bus, -1, VGA)-qdev;
 }
 
+static Property vga_pci_properties[] = {
+DEFINE_PROP_UINT32(vgamem_mb, PCIVGAState, vga.vram_size_mb, 8),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void vga_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -87,6 +92,7 @@ static void vga_class_init(ObjectClass *klass, void *data)
 k-device_id = PCI_DEVICE_ID_QEMU_VGA;
 k-class_id = PCI_CLASS_DISPLAY_VGA;
 dc-vmsd

Re: Question about removing memslots

[Gerd Hoffmann]

  Hi,

 As a workaround you can use -vga std or -vga qxl.  The latter will work
 even better when we have a kernel driver.

There is a kernel driver for -vga std too ;)

http://patchwork.ozlabs.org/patch/145479/

Didn't try on ppc though.  There is a funky #ifdef TARGET_I386 in
vbe_portio_list[], no idea why, but it makes me think a little tweak
could be needed to make it fly.  There shouldn't be any major roadblocks
though.

cheers,
  Gerd
--
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: Question about removing memslots

[Gerd Hoffmann]

  Hi,

 As a workaround you can use -vga std or -vga qxl.  The latter will work
 even better when we have a kernel driver.

There is a kernel driver for -vga std too ;)

http://patchwork.ozlabs.org/patch/145479/

Didn't try on ppc though.  There is a funky #ifdef TARGET_I386 in
vbe_portio_list[], no idea why, but it makes me think a little tweak
could be needed to make it fly.  There shouldn't be any major roadblocks
though.

cheers,
  Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Constantly changing USB product ID

[Gerd Hoffmann]

On 03/27/12 17:48, Jaap Winius wrote:
 Hi folks,
 
 Recently I learned how to configure KVM with USB pass-though
 functionality. In my case I configured my guest domain with this block
 of code:
 
 hostdev mode='subsystem' type='usb' managed='yes'
   source
 vendor id='0x0c93'/
 product id='0x1772'/
 address bus='1' device='4'/
   /source
 /hostdev
 
 At first this worked fine, but then later the guest domain refused to
 start because the USB device was absent.

Not sure what libvirt does there, but qemu can handle this just fine.
If you add '-device usb-host,vendorid=0x0c93,productid=0x1772' qemu will
start just fine no matter if the device is present or not.  You can plug
in in and out as you like and it will show up in the guest when plugged in.

Might be a some security thing, when running qemu depriviledged and
selinux-controlled libvirt probably has to make sure the files in
/dev/bus/usb/ have correct permissions and labels.

 When I checked, I found that
 its product ID had mysteriously changed to 1771. Later it was back at
 1772. Now it appears that the USB device I am dealing with has a product
 ID that changes back and forth between 1771 and 1772 at random.

Guess it has two modes, one real and one install where it presents
itself as mass storage device with windows drivers.

 Apparently, the Windows program running on the guest domain is designed
 to deal with this nonsense, but the question is, Can KVM be configured
 to deal with it? Something like product id='0x177*'/ would be useful,
 but that doesn't work.

qemu is fine with '-device usb-host,vendorid=0x0c93' which will match
any product with from that vendor.  Dunno about the libvirt side.

cheers,
  Gerd

--
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] seabios: add OSHP method stub

[Gerd Hoffmann]

 diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl
 index 442e7a8..3f50169 100644
 --- a/src/ssdt-pcihp.dsl
 +++ b/src/ssdt-pcihp.dsl
 @@ -24,6 +24,7 @@ DefinitionBlock (ssdt-pcihp.aml, SSDT, 0x01, BXPC, 
 BXSSDTPCIHP, 0x1)
 ACPI_EXTRACT_METHOD_STRING aml_ej0_name  \
 Method (_EJ0, 1) { Return(PCEJ(0x##slot)) }  \
 Name (_SUN, 0x##slot)\
 +   Method (OSHP, 1) { Return(0x0) }  \
  }


Linux kernel (kernel-3.2.7-1.fc16.x86_64) complains:

ACPI Warning: For \_SB_.PCI0.S10_.OSHP: Insufficient arguments - needs
1, found 0 (20110623/nspredef-321)

cheers,
  Gerd
--
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 1/2] kvm tools, seabios: Add --bios option to vm run

[Gerd Hoffmann]

On 02/24/12 19:54, Pekka Enberg wrote:
 Hi,
 
 I played around with the --debug-ioport command line option and was able 
 to cheat my way past SeaBIOS POST phase. Should SeaBIOS automatically pick 
 up virtio devices and attempt to boot them?

Yes, it can handle virtio-blk (and soon virtio-scsi too).

You probably want to implement the fw_cfg (firmware config) interface
which is used as communication path between qemu and seabios, to pass
around stuff like e820 table and option roms.

Also http://sgabios.googlecode.com/svn/trunk is nice when working with a
serial console.

HTH,
  Gerd

--
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 1/2] kvm tools, seabios: Add --bios option to vm run

[Gerd Hoffmann]

  Hi,

 So looking at SeaBIOS code, it seems to me we could simply make LKVM
 lie to it by claiming to be coreboot and get away with it, no? We'd
 basically avoid all the PCI allocation passes and such.

I doubt this is going to fly if you want seabios boot from a
virtio-blk-pci device ...

cheers,
  Gerd
--
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 0/4] standard pci bridge device

[Gerd Hoffmann]

On 02/20/12 23:52, Michael S. Tsirkin wrote:
 Here's a new version of the patch.
 
 TODOs:
 - windows guest testing
 
 Changes from v2:
 - added slot id capability
 - migration support
 - misc fixes
 - fix checkpatch errors

64bit prefetch memory window works now:

00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode])
Physical Slot: 16
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at f5126000 (32-bit, non-prefetchable) [size=256]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: f500-f50f
Prefetchable memory behind bridge: f800-fbff
Capabilities: [48] Slot ID: 0 slots, First+, chassis 01
Capabilities: [40] Hot-plug capable
Kernel modules: shpchp

Looks good to me, did only light testing though.

cheers,
  Gerd
--
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-RFC 2/2] pci: add standard bridge device

[Gerd Hoffmann]

  Hi,

 This seems to not support 64bit prefetchable memory windows, at least
 linux doesn't think it does, lspci looks like this:

 00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode])
[ ... ]
 Memory behind bridge: f600-f60f
 Prefetchable memory behind bridge: f800-fbff

 What in the above tells you that 64 bit windows are not supported?

lspci prints 64bit addresses then, like this:

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 1 (rev 03) (prog-if 00 [Normal decode])
[ ... ]
I/O behind bridge: 8000-8fff
Memory behind bridge: c000-c01f
Prefetchable memory behind bridge: c020-c03f

 BAR0 is 32 bit non prefetcheable. As far as I can see linux driver
 takes no precautions against access combining that can
 happen with prefetcheable BARs, so non-prefetcheable
 seems safer.

I'm not talking about bar #0, but about the prefetchable memory window
for devices behind the bridge.

cheers,
  Gerd

--
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-RFC 1/2] shpc: standard hot plug controller

[Gerd Hoffmann]

On 02/13/12 10:15, Michael S. Tsirkin wrote:
 TODO:
 - migration support
 - fix dependency on pci_internals.h

fix checkpatch warnings

cheers,
  Gerd
--
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-RFC 2/2] pci: add standard bridge device

[Gerd Hoffmann]

  Hi,

 +/* If we don't specify the name, the bus will be addressed as id.0, 
 where
 + * id is the parent id.  But it seems more natural to address the bus 
 using
 + * the parent device name. */
 +if (dev-qdev.id  *dev-qdev.id) {
 +br-bus_name = dev-qdev.id;
 +}

That makes the bridge behave different than everybody else.
Not a good idea IMHO.

cheers,
  Gerd

--
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-RFC 2/2] pci: add standard bridge device

[Gerd Hoffmann]

On 02/13/12 10:16, Michael S. Tsirkin wrote:
 This adds support for a standard pci to pci bridge,
 enabling support for more than 32 PCI devices in the system.
 Device hotplug is supported by means of SHPC controller.
 For guests with an SHPC driver, this allows robust hotplug
 and even hotplug of nested bridges, up to 31 devices
 per bridge.

This seems to not support 64bit prefetchable memory windows, at least
linux doesn't think it does, lspci looks like this:

00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode])
Physical Slot: 16
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Region 0: Memory at f6126000 (32-bit, non-prefetchable) [size=256]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: f600-f60f
Prefetchable memory behind bridge: f800-fbff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Hot-plug capable
Kernel modules: shpchp

Intentional?

cheers,
  Gerd
--
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: Inconsistent vgabios reference

[Gerd Hoffmann]

  Hi,

 Now, I've a question: what seabios implementation of extboot we're
 talking about?

seabios boots natively from virtio now, so for that use case extboot
isn't needed any more.

  -option-rom which is impossible to select as a first
 boot device?

'qemu-kvm -option-rom romfile=/root/roms/8xx_64.rom,bootindex=1' will do.

HTH,
  Gerd

--
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: building vgabios-stdvga.bin

[Gerd Hoffmann]

  Hi,

 I don't know if this is the right place to make this suggestion,
 but it would be nice if this version could make it into the
 qemu-kvm distribution.

 Do you know what the real constraints are?  Do you know if they're
 imposed by the vgabios driver, the VNC module, or the guest
 operating system (Windows 7 in this case)?

vnc works with 16x16 internally, so a multiple of 16 should be fine.

Reminds me of a bug, I've trapped into this before, digging ...

Patch attached.  Seems to be still not applied, has been on the
qemu-devel list several times already :-(

HTH,
  Gerd
commit a22fe41d90d484a68317e0ac46785611afab545f
Author: Gerd Hoffmann kra...@redhat.com
Date:   Mon Jun 14 12:28:23 2010 +0200

Fix vnc memory corruption with width = 1400

vnc assumes that the screen width is a multiple of 16 in several places.
If this is not the case vnc will overrun buffers, corrupt memory, make
qemu crash.

This is the minimum fix for this bug. It makes sure we don't overrun the
scanline, thereby fixing the segfault.  The rendering is *not* correct
though, there is a black border at the right side of the screen, 8
pixels wide because 1400 % 16 == 8.

Signed-off-by: Gerd Hoffmann kra...@redhat.com

diff --git a/ui/vnc.c b/ui/vnc.c
index e85ee66..afbf82c 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2445,7 +2445,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
 guest_ptr  = guest_row;
 server_ptr = server_row;
 
-for (x = 0; x  vd-guest.ds-width;
+for (x = 0; x + 15  vd-guest.ds-width;
 x += 16, guest_ptr += cmp_bytes, server_ptr += cmp_bytes) {
 if (!test_and_clear_bit((x / 16), vd-guest.dirty[y]))
 continue;

Re: Building vgabios-stdvga.bin

[Gerd Hoffmann]

  Hi,

 I noticed that there's a directory, kvm/vgabios, in the distribution
 which appears to have source code for the relevant targets.  Indeed,
 one of the source files there, vbetables-gen.c, seems to be the one
 I need to modify to add my new display resolutions.  Great.
 So naturally, I tried to run a make there, but it wanted to use bcc.

Thats the one qemu is using.  Also available from
http://git.qemu.org/?p=vgabios.git;a=summary

 With this questionable version of dev86, I went back to the kvm/vgabios
 directory and tried to build there again.  Much to my surprise, it
 actually ran, and built 4 variants on VGABIOS-lgpl-latest.bin...
 Cool, says I, now what do I do with these?  I did the only thing
 I could think of, and installed VGA-lgpl-latest.bin as

Almost correct.  You need VGABIOS-lgpl-latest.stdvga.bin

 Of course, what this thing really needs is a way for us to configure,
 at runtime, the available resolutions.  I have no idea how hard that
 would be, but we're obviously not there now.

There is some work in progress to put the vgabios included in
seabios.git into better shape, which hopefully gives us a vgabios which
does (a) does not require dev86 to build and (b) is almost completely c
code not assembler and thus much easier to hack.

There is a communication channel between seabios  qemu already
(fw_cfg), that could be used by vgabios too to get non-standard screen
resolutions configured at runtime.

cheers,
  Gerd

--
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: [FYI] Need to do a full rebuild if you are on Linux x86 host

[Gerd Hoffmann]

On 11/22/11 01:25, Anthony Liguori wrote:
 Due to this commit:
 
 commit 40d6444e91c6ab17e5e8ab01d4eece90cbc4afed
 Author: Avi Kivity a...@redhat.com
 Date:   Tue Nov 15 20:12:17 2011 +0200
 
 configure: build position independent executables on x86-Linux hosts
 
 PIE binaries cannot be linked with non-PIE binaries and make is not
 smart enough to rebuild when the CFLAGS have changed.

Breaks build on RHEL-5 and probably also other not-so-recent linux distros.

[ ... ]
  CCi386-softmmu/exec.o
[ ... ]
  LINK  i386-softmmu/qemu-system-i386
/usr/bin/ld: exec.o: relocation R_X86_64_TPOFF32 against
`tls__cpu_single_env' can not be used when making a shared object;
recompile with -fPIC
exec.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [qemu-system-i386] Error 1
make: *** [subdir-i386-softmmu] Error 2

cheers,
  Gerd

PS: for those with ipv6 connectivity the full log is available at
http://spunk.home.kraxel.org/bb/builders/rhel5-default/builds/98/steps/compile/logs/stdio
--
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: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Gerd Hoffmann]

  Hi,

 As far I know it is pretty much impossible to figure the
 foreground/background colors of the terminal you are running on.  You

 Glad to hear that, I thought I hadn't researched that much (I did). Hope
 somebody appears and tell us how it is done :-)
 
 In xterm, '\e]10;?\e\\' and '\e]11;?\e\\' will report the colors, e.g.:
 
 #!/bin/bash
   read -s -r -d \\ -p `printf '\e]10;?\e\\'` -t 1 fg
   [ $? -ne 0 ]  fg=no response
   echo foreground: $fg | cat -v
   read -s -r -d \\ -p `printf '\e]11;?\e\\'` -t 1 bg
   [ $? -ne 0 ]  bg=no response
   echo background: $bg | cat -v

Works fine in xterm.  Neither gnome-terminal (i.e. vte widget) nor
konsole support this though.

cheers,
  Gerd
--
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: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Gerd Hoffmann]

  Hi,

 What we want to have is to have a set of distinctive colors - just 
 two (background, foreground) colors are not enough - we also need 
 colors to highlight certain information - we need 5-6 colors for the 
 output to be maximally expressive. Is there a canonical way to handle 
 that while still adapting to user preferences automatically by taking 
 background/foreground color scheme of the xterm into account?

 I suspect to fix the worst of the fallout we could add some logic to 
 detect low contrast combinations (too low color distance) and fall 
 back to the foreground/background colors in that case.

As far I know it is pretty much impossible to figure the
foreground/background colors of the terminal you are running on.  You
can try some guesswork based on $TERM (linux console usually has black
background, xterm is white by default), but there will always be cases
where it fails.

You can run without colors.  You can use bold to highlight things and
reverse for the cursor.  Surely a bit limited and not as pretty as
colored, but works for sure everywhere.

You can go for a linux-console style black background.  Pretty much any
color is readable here, so you should have no problems at all to find
the 5-6 colors you want.

You can go for a xterm-like light background, for example the lightgray
used by older perf versions.  I like that background color, problem is
with most colors the contrast is pretty low.  IMHO only red, blue and
violet are readable on lightgray.  And black of course.

 Plus allowing full .perfconfig configurability of all the relevant 
 colors, for those with special taste.

Sure.  Maybe also allow multiple color sections and pick them by $TERM
or --colors switch, i.e. [colors xterm].

cheers,
  Gerd
--
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: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Gerd Hoffmann]

  Hi,

 Plus allowing full .perfconfig configurability of all the relevant 
 colors, for those with special taste.

 Sure.  Maybe also allow multiple color sections and pick them by $TERM
 or --colors switch, i.e. [colors xterm].
 
 Its fully configurable as of now, what we need is a set of .perfconfigs
 that show how people think its better, we try it, set it as the default,
 leave the others in tools/perf/Documentation/perfconfig/color.examples.

Yep, a set of examples works too.

The colors are not fully configurable yet though.  First, when switching
all five colorsets to default, default there are still things which
are colored (top bar, bottom bar, keys help display).  Second there is
no way to set terminal attributes (i.e. top = bold or selected =
reverse).

cheers,
  Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH 2/2] ac97: don't override the pci subsystem id

[Gerd Hoffmann]

On 11/07/11 17:00, Anthony Liguori wrote:
 On 11/07/2011 09:33 AM, Gerd Hoffmann wrote:
 This patch removes the code lines which set the subsystem id for the
 emulated ac97 card to 8086:.  Due to the device id being zero the
 subsystem id isn't vaild anyway.  With the patch applied the sound card
 gets the default qemu subsystem id (1af4:1100) instead.
 
 I don't like having a property of use broken.

Well, it *is* broken.
Suggestions for a better name?

 Wouldn't it be better to have the subsystem vendor and device id be
 configurable, set the default to the qemu subsystem ids, and then set it
 to 8086: for  1.0?

I don't want this being fully configurable just for the snake of
backward compatibility with old qemu versions.

cheers,
  Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH 2/2] ac97: don't override the pci subsystem id

[Gerd Hoffmann]

  Hi,

 Wouldn't it be better to have the subsystem vendor and device id be
 configurable, set the default to the qemu subsystem ids, and then set it
 to 8086: for  1.0?

 I don't want this being fully configurable just for the snake of
 backward compatibility with old qemu versions.
 
 I imagine some downstreams will want to configure it, but if we ever do
 that, it's not for 1.0.

And for that it would make more sense to make the default qemu subsystem
id configurable, not the individual device IDs ...

cheers,
  Gerd
--
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: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Gerd Hoffmann]

  Hi,

 Indeed, documentation is lacking, I think coming from a kernel
 standpoint I relied too much in the documentation is source code
 mantra of old days.

Sorry for the shameless plug, but as you are speaking of lacking
documentation:  Where the heck is the perf config file documented, other
than source code?  Reading the parser to figure how the config file is
supposed to look like really isn't fun :(

I'm looking for a way to disable the colors in the perf report tui.  Or
configure them into something readable.  No, light green on light gray
which is used by default isn't readable.

thanks,
  Gerd
--
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: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Gerd Hoffmann]

  Hi,

 documentation:  Where the heck is the perf config file documented, other
 than source code?  Reading the parser to figure how the config file is
 supposed to look like really isn't fun :(
  
 I'm looking for a way to disable the colors in the perf report tui.  Or
 configure them into something readable.  No, light green on light gray
 which is used by default isn't readable.
 
 That was fixed in 3.2-rc1, where also we have:

Very cutting edge.  /me pulls.

 [acme@felicio linux]$ cat tools/perf/Documentation/perfconfig.example

Present now, thanks.

 [colors]
 
   # These were the old defaults
   top = red, lightgray
   medium = green, lightgray
   normal = black, lightgray
   selected = lightgray, magenta
   code = blue, lightgray

Seems to have no effect, guess the distro perf binary is too old for
that (RHEL-6).

 [tui]
 
   report = off

That works.  I don't want turn off the tui altogether though, I actually
like the interactive expanding+collapsing of the call graphs.  I just
want turn off the colors.

perf_color_default_config() in util/color.c seems to lookup a color.ui
config variable.  Can I set that somehow?  Tried ui= in a [color]
section -- no effect.

 By default the TUI now uses whatever color is configured for your xterm,
 not something fixed as in the past, which was a common source of
 complaints, that, unfortunately I only heard indirectly :-\
 
 Ah, if you still need to configure the colors, use default so that it
 will use whatever is the color configured in your
 xterm/gnome-terminal/whatever profile.
 
 For reference, the default set of colors now is (from
 tools/perf/util/ui/browser.c):
 
 static struct ui_browser__colorset {
 const char *name, *fg, *bg;
 int colorset;
 } ui_browser__colorsets[] = {
 {
 .colorset = HE_COLORSET_TOP,
 .name = top,
 .fg   = red,
 .bg   = default,

Bad idea IMO.  Setting only one of foreground+background gives pretty
much unpredictable results.  My xterms have different background colors,
the ones with a root shell happen to have a (dark) red background.
Which results in red-on-dark-red text.  Not good.

I'd strongly suggest to either set both background and foreground to
default or to set both to a specific color.  When doing the latter make
sure the colors have enougth contrast so they are readable.

cheers,
  Gerd
--
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: Wierd hack to sound/pci/intel8x0.c

[Gerd Hoffmann]

  Hi,

 Agreed.  If we can know the virtual device for KVM in a better way
 (e.g. any specific PCI SSID or such), we can narrow the condition more
 safely.

PCI Subsystem ID 1af4:1100 is qemu/kvm (not only Intel HDA, most other
emulated pci devices have it too). Complete entry:

00:04.0 0403: 8086:2668 (rev 01)
Subsystem: 1af4:1100
Physical Slot: 4
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at e203 (32-bit, non-prefetchable) [size=16K]
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel

cheers,
  Gerd
--
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] KVM: Add wrapper script around QEMU to test kernels

[Gerd Hoffmann]

  Hi,

 Usable - I've tried kvm-tool several times and still (today) fail to
 get a standard SUSE image (with a kernel I have to compile and provide
 separately...) up and running *). Likely a user mistake, but none that
 is very obvious. At least to me.

Same here.

No support for booting from CDROM.
No support for booting from Network.
Thus no way to install a new guest image.

Booting an existing qcow2 guest image failed, the guest started throwing
I/O errors.  And even to try that I had to manually extract the kernel
and initrd images from the guest.  Maybe you should check with the Xen
guys, they have a funky 'pygrub' which sort-of automates the
copy-kernel-from-guest-image process.

Booting the host kernel failed too.  Standard distro kernel.  The virtio
bits are modular, not statically compiled into the kernel.  kvm tool
can't handle that.

You have to build your own kernel and make sure you flip the correct
config bits, then you can boot it to a shell prompt.  Trying anything
else just doesn't work today ...

cheers,
  Gerd
--
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] KVM: Add wrapper script around QEMU to test kernels

[Gerd Hoffmann]

  Hi,

 It's not just about code, it's as much about culture and development process.

Indeed.  The BSDs have both kernel and the base system in a single
repository.  There are probably good reasons for (and against) it.

In Linux we don't have that culture.  No tool (except perf) lives in the
kernel repo.  I fail to see why kvm-tool is that much different from
udev, util-linux, iproute, filesystem tools, that it should be included.

cheers,
  Gerd
--
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