[Qemu-devel] virtio-blk wierd memcpy

In my failing attempts to valgrind qemu (how to people live like this?), I spotted this in the logs ==19521== Source and destination overlap in memcpy(0x31d38938, 0x31d38938, 64) ==19521==at 0x4A0A343: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19521==

Re: [Qemu-devel] Multi-head support RFC

On Wed, Nov 6, 2013 at 6:42 AM, John Baboval john.babo...@citrix.com wrote: Hello, I am currently the device model maintainer for XenClient Enterprise. As you may or may not know, we maintain a patch queue on top of QEMU (currently 1.3) that adds functionality needed to support XCE features.

Re: [Qemu-devel] Multi-head support RFC

On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, It currently just adds multiple DisplaySurfaces to the QemuConsole, now Gerd said he thought I should be using multiple QemuConsoles but I really didn't think this was a good idea, Why? It's a fair question and I

[Qemu-devel] [PATCH] ui/sdl2 : initial port to SDL 2.0

From: Dave Airlie airl...@redhat.com I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface. The biggest changes were in the input handling, where SDL2 has done a major overhaul, and I've had to include a generated translation file to get from SDL2 codes back to qemu

Re: [Qemu-devel] [PATCH] ui/sdl2 : initial port to SDL 2.0

On Mon, Nov 11, 2013 at 2:02 PM, Anthony Liguori anth...@codemonkey.ws wrote: On Sun, Nov 10, 2013 at 3:15 PM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface. The biggest changes were

Re: [Qemu-devel] [PATCH] ui/sdl2 : initial port to SDL 2.0

On Tue, Nov 12, 2013 at 12:07 AM, Anthony Liguori anth...@codemonkey.ws wrote: On Nov 11, 2013 1:10 AM, Dave Airlie airl...@gmail.com wrote: On Mon, Nov 11, 2013 at 2:02 PM, Anthony Liguori anth...@codemonkey.ws wrote: On Sun, Nov 10, 2013 at 3:15 PM, Dave Airlie airl...@gmail.com wrote

Re: [Qemu-devel] [PATCH] vfio-pci: Fix Nvidia MSI ACK through 0x88000 quirk

On Tue, Nov 12, 2013 at 7:43 AM, Alex Williamson alex.william...@redhat.com wrote: When MSI is enabled on Nvidia GeForce cards the driver seems to acknowledge the interrupt by writing a 0xff byte to the MSI capability ID register using the PCI config space mirror at offset 0x88000 from BAR0.

Re: [Qemu-devel] [PATCH] vfio-pci: Fix Nvidia MSI ACK through 0x88000 quirk

On Tue, Nov 12, 2013 at 8:32 AM, Alex Williamson alex.william...@redhat.com wrote: On Tue, 2013-11-12 at 07:55 +1000, Dave Airlie wrote: On Tue, Nov 12, 2013 at 7:43 AM, Alex Williamson alex.william...@redhat.com wrote: When MSI is enabled on Nvidia GeForce cards the driver seems

[Qemu-devel] dataplane, thread and gpu stuff

Hi, So after talking to a few people at kvm forum I think the GPU code should probably use the dataplane stuff from the outset, The main advantages I think this gives me is being able to dequeue objects from the vq from a thread and send irq vectors from there as well. Though since it appears

[Qemu-devel] console muti-head some more design input

So I've started banging my head against using QemuConsole as the container for a single output, and have been left with the usual 10 ways to design things, but since I don't want to spend ages implementing one way just to be told its unacceptable it would be good to get some more up front design

Re: [Qemu-devel] console muti-head some more design input

On Tue, Nov 19, 2013 at 6:11 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, So I felt I had a choice here for sharing a single output surface amongst outputs: a) have multiple QemuConsole reference multiple DisplaySurface wihch reference a single pixman image, This one. In either case

Re: [Qemu-devel] console muti-head some more design input

Have a look the virtio-gpu branch in my repo (don't look at the history, its ugly, just the final state), you'll see code in sdl2.c to do input translation from window coordinates to the overall screen space. So we need at least the x,y offset in the ui code, and I think we need to

Re: [Qemu-devel] console muti-head some more design input

On Wed, Nov 20, 2013 at 3:17 PM, Dave Airlie airl...@gmail.com wrote: Have a look the virtio-gpu branch in my repo (don't look at the history, its ugly, just the final state), you'll see code in sdl2.c to do input translation from window coordinates to the overall screen space. So we need

[Qemu-devel] [PATCH 2/8] console: add state notifiers for ui-display

From: Dave Airlie airl...@redhat.com These are to be used for the UI to signal the video display, and vice-versa about changes in the state of a console, like size and offsets in relation to other consoles for input handling. Signed-off-by: Dave Airlie airl...@redhat.com --- include/ui

[Qemu-devel] [RFC] virtio-gpu and sdl2 so far

Hey, I thought I should post this for a bit more feedback and show where I've gone so far, all available in git http://cgit.freedesktop.org/~airlied/qemu/log/?h=virtio-gpu The first patch is the sdl2 port with some minor changes I posted before, then there are a bunch of console changes that I

[Qemu-devel] [PATCH 4/8] console: add ability to wrap a console.

From: Dave Airlie airl...@redhat.com In order to implement virtio-vga on top of virtio-gpu we need to be able to wrap the first console virtio-gpu registers from inside virtio-vga which initialises after virtio-gpu. With this interface virtio-vga can store the virtio-gpu interfaces, and call them

[Qemu-devel] [PATCH 1/8] ui/sdl2 : initial port to SDL 2.0 (v1.2)

From: Dave Airlie airl...@redhat.com I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface. The biggest changes were in the input handling, where SDL2 has done a major overhaul, and I've had to include a generated translation file to get from SDL2 codes back to qemu

[Qemu-devel] [PATCH 3/8] console: add information retrival wrappers

From: Dave Airlie airl...@redhat.com We need to know how many graphics consoles are registered in the UI code so it knows how many windows it should prepare for etc, also so that it could potentially warn for cases it can't handle. We also need to know the console index so we can add

[Qemu-devel] [PATCH 8/8] HACK: just to make things start easier with libvirt

From: Dave Airlie airl...@redhat.com --- hw/display/vga-pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c index b3a45c8..e4bea17 100644 --- a/hw/display/vga-pci.c +++ b/hw/display/vga-pci.c @@ -146,6 +146,7 @@ static int

[Qemu-devel] [PATCH 5/8] sdl2: update for multihead support.

From: Dave Airlie airl...@redhat.com This reworks the complete SDL2 code to support multi-head, by using DisplayChangeListeners wrapped inside a structure per-head, containing the SDL2 information along with the console info. This also adds a hack to allow Ctrl-Alt-n to toggle the first console

[Qemu-devel] [PATCH 6/8] virtio-gpu: v0.1 of the virtio based GPU code.

From: Dave Airlie airl...@redhat.com This is the basic virtio-gpu which is multi-head capable, ARGB cursor support, unaccelerated. Signed-off-by: Dave Airlie airl...@redhat.com --- default-configs/x86_64-softmmu.mak | 1 + hw/display/Makefile.objs | 2 + hw/display/virtgpu_hw.h

[Qemu-devel] [PATCH 7/8] virtio-vga: v1

From: Dave Airlie airl...@redhat.com This is a virtio-vga device built on top of the virtio-gpu device. Signed-off-by: Dave Airlie airl...@redhat.com --- Makefile | 2 +- default-configs/x86_64-softmmu.mak | 1 + hw/display/Makefile.objs | 1 + hw

Re: [Qemu-devel] console muti-head some more design input

On Thu, Nov 21, 2013 at 1:14 AM, Gerd Hoffmann kra...@redhat.com wrote: On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote: On 11/20/2013 03:12 AM, Gerd Hoffmann wrote: Hi, I think you are only considering output here, for input we definitely need some idea of screen layout, and

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

On Wed, Nov 20, 2013 at 10:02 PM, Gerd Hoffmann kra...@redhat.com wrote: On Mi, 2013-11-20 at 15:52 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com This is a virtio-vga device built on top of the virtio-gpu device. Ah, I see what you use the wrapping for. Hmm. I think you

Re: [Qemu-devel] console muti-head some more design input

On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, While thinking about this: A completely different approach to tackle this would be to implement touchscreen emulation. So we don't have a single usb-tablet, but multiple (one per display) touch input devices.

Re: [Qemu-devel] sending SEGV to qemu crashes host kernel in Fedora 19

On Tue, Jul 9, 2013 at 10:35 AM, Dave Airlie airl...@gmail.com wrote: Hi, F19 kernel-3.9.8-300.fc19.x86_64 qemu-kvm-1.4.2-4.fc19.x86_64 If I start a complete F19 install in the guest and send the qemu process a SEGV signal, the host kernel starts giving me random kmalloc errors soon after

[Qemu-devel] sending SEGV to qemu crashes host kernel in Fedora 19

Hi, F19 kernel-3.9.8-300.fc19.x86_64 qemu-kvm-1.4.2-4.fc19.x86_64 If I start a complete F19 install in the guest and send the qemu process a SEGV signal, the host kernel starts giving me random kmalloc errors soon after, if I send a normal kill signal things seem fine. CPU is Intel(R) Core(TM)

[Qemu-devel] virtio indirect with lots of descriptors

Hi Rusty, playing with my virtio gpu, I started hitting the qemu error_report(Too many read descriptors in indirect table); Now I'm not sure but this doesn't seem to be a virtio limit that the guest catches from what I can see, since my host dies quite quickly, when I'm doing transfers in/out of

[Qemu-devel] Introducing Virgil - 3D virtual GPU for qemu

Hey Mesa + qemu lists, since I suppose these communities would be most interested in this and might not all read my blog or G+ stream, Virgil is a research project I've been working on at Red Hat for a few months now and I think is ready for at least announcing upstream and seeing if there is

[Qemu-devel] gpu and console chicken and egg

So I've hit a bit of a init ordering issue that I'm not sure how best to solve, Just some background: In order for the virt GPU and the UI layer (SDL or GTK etc) to interact properly over OpenGL use, I have created and OpenGL provider in the console, and the UI layer can register callbacks for a

Re: [Qemu-devel] gpu and console chicken and egg

On Wed, Dec 4, 2013 at 6:23 PM, Gerd Hoffmann kra...@redhat.com wrote: On Mi, 2013-12-04 at 17:02 +1000, Dave Airlie wrote: So I've hit a bit of a init ordering issue that I'm not sure how best to solve, Just some background: In order for the virt GPU and the UI layer (SDL or GTK etc

Re: [Qemu-devel] gpu and console chicken and egg

On Thu, Dec 5, 2013 at 6:52 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, Hmm, why does it depend on the UI? Wasn't the plan to render into a dma-buf no matter what? Then either read the rendered result from the dmabuf (non-gl UI like vnc) or let the (gl-capable) UI pass the dma-buf

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

On Thu, Nov 21, 2013 at 9:06 PM, Gerd Hoffmann kra...@redhat.com wrote: On Do, 2013-11-21 at 13:12 +1000, Dave Airlie wrote: On Wed, Nov 20, 2013 at 10:02 PM, Gerd Hoffmann kra...@redhat.com wrote: On Mi, 2013-11-20 at 15:52 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

On Fri, Dec 6, 2013 at 6:24 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, Now the advice given was to have virtio-vga wrap virtio-gpu-base but from what I can see it really can't. Since it needs to act and look like a PCI device Oops, yes. VirtIOPCIProxy wasn't on my radar. That makes

[Qemu-devel] gtk3 mouse warping

does the gtk3 mouse warping work for anyone else? I've just been testing with gtk3 + virtio-vga and the mouse seems to bounce around a lot off the edges of the window, but never make it into it. Dave.

Re: [Qemu-devel] gtk3 mouse warping

On Mon, Dec 9, 2013 at 10:49 AM, Dave Airlie airl...@gmail.com wrote: does the gtk3 mouse warping work for anyone else? I've just been testing with gtk3 + virtio-vga and the mouse seems to bounce around a lot off the edges of the window, but never make it into it. It appears to be an issue

Re: [Qemu-devel] gtk3 mouse warping

On Mon, Dec 9, 2013 at 1:54 PM, Dave Airlie airl...@gmail.com wrote: On Mon, Dec 9, 2013 at 10:49 AM, Dave Airlie airl...@gmail.com wrote: does the gtk3 mouse warping work for anyone else? I've just been testing with gtk3 + virtio-vga and the mouse seems to bounce around a lot off the edges

[Qemu-devel] [PATCH 1/2] gtk: don't warp point in absolute mode

From: Dave Airlie airl...@redhat.com This makes gtk act the same way as the current sdl backend, which doesn't do the warp in this case. If your guest GPU has hw pointer this leads you get endless loops where the warp causes motion causes input events, causes the guest to move the cursor causes

[Qemu-devel] [PATCH 2/2] gtk: respect cursor visibility

From: Dave Airlie airl...@redhat.com If the guest asks for no cursor, switch gtk to using the null cursor. Signed-off-by: Dave Airlie airl...@redhat.com --- ui/gtk.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/ui/gtk.c b/ui/gtk.c index 2abf289

[Qemu-devel] gtk cursor patches

These were just fallout fixes from exploring gtk multi-head with virtio-gpu, hopefully they are useful to people before then, not sure if the warping/absolute interaction is defined or not. Dave.

[Qemu-devel] [PATCH 5/8] console: add ability to wrap a console.

From: Dave Airlie airl...@redhat.com In order to implement virtio-vga on top of virtio-gpu we need to be able to wrap the first console virtio-gpu registers from inside virtio-vga which initialises after virtio-gpu. With this interface virtio-vga can store the virtio-gpu interfaces, and call them

[Qemu-devel] [RFC] sdl2 + virtio-gpu repost

Hi, This is a repost of the latest SDL2 UI layer along with virtio-gpu, I've merged the SDL2 base and multi-head patches into one, and I've split out the display notifiers stuff and the sdl2 demo hack. The virtio-gpu/vga wrapping is still unresolved, I've failed to find a cleaner way yet,

[Qemu-devel] [PATCH 1/8] ui/sdl2 : initial port to SDL 2.0 (v2.0)

From: Dave Airlie airl...@redhat.com I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface. The biggest changes were in the input handling, where SDL2 has done a major overhaul, and I've had to include a generated translation file to get from SDL2 codes back to qemu

[Qemu-devel] [PATCH 2/8] console: add state notifiers for ui-display

From: Dave Airlie airl...@redhat.com These are to be used for the UI to signal the video display, and vice-versa about changes in the state of a console, like size and offsets in relation to other consoles for input handling. Signed-off-by: Dave Airlie airl...@redhat.com --- include/ui

[Qemu-devel] [PATCH 6/8] virtio-gpu: v0.2 of the virtio based GPU code.

From: Dave Airlie airl...@redhat.com This is the basic virtio-gpu which is multi-head capable, ARGB cursor support, unaccelerated. Some more info is in docs/specs/virtio-gpu.txt. changes since v0.1: add reset handling fix display info response fix cursor generation issues drop 3d stuff

[Qemu-devel] [PATCH 3/8] sdl2: add display notify change support

From: Dave Airlie airl...@redhat.com this adds support for the callbacks from the console layer, when the gpu changes the layouts. Signed-off-by: Dave Airlie airl...@redhat.com --- ui/sdl2.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/ui/sdl2.c b/ui/sdl2.c index 2eb3e9c

[Qemu-devel] [PATCH 4/8] sdl2: add UI to toggle head 1 on/off

From: Dave Airlie airl...@redhat.com This just adds ctrl-alt-n to toggle head 1 on/off for testing and demo purposes. Signed-off-by: Dave Airlie airl...@redhat.com --- ui/sdl2.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/ui/sdl2.c b/ui/sdl2.c index dd8cd2b..c52dcd9 100644

[Qemu-devel] [PATCH 7/8] virtio-vga: v1

From: Dave Airlie airl...@redhat.com This is a virtio-vga device built on top of the virtio-gpu device. Signed-off-by: Dave Airlie airl...@redhat.com --- Makefile | 2 +- default-configs/x86_64-softmmu.mak | 1 + hw/display/Makefile.objs | 1 + hw

[Qemu-devel] [PATCH 8/8] HACK: just to make things start easier with libvirt

From: Dave Airlie airl...@redhat.com --- hw/display/vga-pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c index b3a45c8..e4bea17 100644 --- a/hw/display/vga-pci.c +++ b/hw/display/vga-pci.c @@ -146,6 +146,7 @@ static int

[Qemu-devel] [PATCH] virtio-gpu: use glib alloc/free routines

From: Dave Airlie airl...@redhat.com Oh I forgot to fix these up previously. Signed-off-by: Dave Airlie airl...@redhat.com --- hw/display/virtio-gpu.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c index

Re: [Qemu-devel] [RFC] sdl2 + virtio-gpu repost

On Tue, Dec 10, 2013 at 2:05 PM, Dave Airlie airl...@gmail.com wrote: Hi, This is a repost of the latest SDL2 UI layer along with virtio-gpu, I've merged the SDL2 base and multi-head patches into one, and I've split out the display notifiers stuff and the sdl2 demo hack. The virtio-gpu/vga

Re: [Qemu-devel] [PATCH 1/8] ui/sdl2 : initial port to SDL 2.0 (v2.0)

On Wed, Dec 11, 2013 at 12:35 AM, Gerd Hoffmann kra...@redhat.com wrote: Hi, The biggest changes were in the input handling, where SDL2 has done a major overhaul, and I've had to include a generated translation file to get from SDL2 codes back to qemu compatible ones. I'm still not sure how

[Qemu-devel] issue with vgabios lfb and virtio vga

Hi Gerd, so I have a bit of a conflict I'm not sure how best to handle between how vgabios.c locates its LFB and how virtio requires the BAR get laid out. So virtio-pci requires the BARs are laid out for MSI support with the config i/o ports at BAR 0, and MSI BAR at BAR 1. Now the vgabios.c

Re: [Qemu-devel] issue with vgabios lfb and virtio vga

On Thu, Dec 12, 2013 at 6:17 PM, Gerd Hoffmann kra...@redhat.com wrote: On Do, 2013-12-12 at 09:51 +1000, Dave Airlie wrote: Now the vgabios.c does a check of bar 0 and bar 1 to see if they are 0xfff1 masked, this protects against the the i/o bar but fails to protect against the LFB one as PCI

Re: [Qemu-devel] [PATCH 01/42] ui/sdl2 : initial port to SDL 2.0 (v2.0)

On Tue, Dec 17, 2013 at 8:12 AM, Stefan Weil s...@weilnetz.de wrote: Am 16.12.2013 11:48, schrieb Gerd Hoffmann: From: Dave Airlie airl...@redhat.com I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface. The biggest changes were in the input handling, where SDL2 has

[Qemu-devel] vmware video broken in git

Hi guys, Building 0.11.0, qemu -vga vmware -sdl works fine. with git I just get a blank screen. I'm trying to bisect but I keep running into a big chunk of NIC changes where none of the drivers compile, so I thought maybe someone could make an educated guess. Dave.

[Qemu-devel] [PATCH] vmware_vga: add rom file so that it boots.

From: Dave Airlie airl...@redhat.com This just adds the rom file to the vmware SVGA chipset so it boots. Signed-off-by: Dave Airlie airl...@redhat.com --- hw/vmware_vga.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c index 240731a

Re: [Qemu-devel] vmware video broken in git

On Fri, Dec 11, 2009 at 5:11 PM, Mark McLoughlin mar...@redhat.com wrote: Hi Dave, On Fri, 2009-12-11 at 14:59 +1000, Dave Airlie wrote: Hi guys, Building 0.11.0, qemu -vga vmware -sdl works fine. with git I just get a blank screen. I'm trying to bisect but I keep running into a big chunk

[Qemu-devel] approaches to 3D virtualisation

So I've been musing on the addition of some sort of 3D passthrough for qemu (as I'm sure have lots of ppl) But I think the goals of such an addition need to be discussed prior to anyone writing a line of code. Current existing solutions in the area: a) VMware virtual graphics adapter - based on

[Qemu-devel] Re: approaches to 3D virtualisation

Oops gmail send this, silly laptop has a mind of its own sometimes. On Sat, Dec 12, 2009 at 11:58 AM, Dave Airlie airl...@gmail.com wrote: So I've been musing on the addition of some sort of 3D passthrough for qemu (as I'm sure have lots of ppl) But I think the goals of such an addition need

Re: [Qemu-devel] X support for QXL and SPICE

On Sat, Dec 12, 2009 at 1:31 PM, Anthony Liguori anth...@codemonkey.ws wrote: Soeren Sandmann wrote: Hi, Here is an overview of what the current QXL driver does and does not do.  The parts of X rendering that are currently being used by cairo and Qt are: - Most of XRender        - Image

[Qemu-devel] Re: approaches to 3D virtualisation

Current existing solutions in the area: a) VMware virtual graphics adapter - based on DX9, has an open KMS/Gallium3D driver stack recently released by vmware, has certified Windows drivers and has a documented vGPU interface (it could be documented a lot better)

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

On Sun, Dec 13, 2009 at 5:28 AM, Anthony Liguori anth...@codemonkey.ws wrote: Izik Eidus wrote: That specific area in spice will be changed very soon due to new requiments that the offscreens will add. Windows direct draw allow modifying offscreen (or even primary) surfaces using a pointer

Re: [Qemu-devel] Re: approaches to 3D virtualisation

On Sun, Dec 13, 2009 at 1:23 AM, Anthony Liguori anth...@codemonkey.ws wrote: Juan Quintela wrote: Dave Airlie airl...@gmail.com wrote: Current existing solutions in the area: a) VMware virtual graphics adapter - based on DX9, has an open KMS/Gallium3D driver stack recently released

[Qemu-devel] vmware vga + kvm interaction

If I boot an F12 LiveCD with vmware VGA without KVM enabled, I get the syslinux boot screen and can pick options, the same qemu run with -enable-kvm, I just get a blank screen. Anyone have any clues on why this might be? all with latest git tree. Dave.

Re: [Qemu-devel] vmware vga + kvm interaction

On Mon, Dec 14, 2009 at 3:59 AM, Anthony Liguori anth...@codemonkey.ws wrote: Avi Kivity wrote: On 12/13/2009 10:55 AM, Dave Airlie wrote: If I boot an F12 LiveCD with vmware VGA without KVM enabled, I get the syslinux boot screen and can pick options, the same qemu run with -enable-kvm, I

Re: [Qemu-devel] vmware vga + kvm interaction

On Tue, Dec 15, 2009 at 12:28 AM, Anthony Liguori anth...@codemonkey.ws wrote: Dave Airlie wrote: I actually reinvented at least one of the patches locally and it didn't seem to help, but I'll try and take a closer look today, http://repo.or.cz/w/qemu/aliguori-queue.git vmware-vga-for-dave

[Qemu-devel] vmware fixes in a git tree

Hi guys, I've gotten vmware going again on master using some patches from Anthony (rebased onto master) and a fix for the cursor pixmap which was causing a segfault. The patches are in git://people.freedesktop.org/~airlied/qemu.git vmware-queue

[Qemu-devel] qemu fixup patch sequence.

First patch adds a second PCI BAR as per the VMware SVGA specification for the fifo instead of using the top of the VRAM BAR. Patches 2-5 are from Anthony and I just rebased them on top of master. Patch6: fixes a crasher in vmware when X starts inside the guest. I've booted these with an F12

[Qemu-devel] [PATCH 2/6] Make sure to enable dirty tracking of VBE vram mapping

...@us.ibm.com Rebased-by: Dave Airlie airl...@redhat.com --- hw/vga-isa.c|6 +- hw/vga-pci.c|7 +-- hw/vga.c| 24 hw/vga_int.h|5 +++-- hw/vmware_vga.c |8 ++-- 5 files changed, 31 insertions(+), 19 deletions(-) diff --git a/hw/vga

[Qemu-devel] [PATCH 1/6] vmware: setup PCI BAR 2 for FIFO as per vmware spec

From: Dave Airlie airl...@linux.ie --- hw/vmware_vga.c | 35 ++- 1 files changed, 30 insertions(+), 5 deletions(-) diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c index f3e3749..28bbc3f 100644 --- a/hw/vmware_vga.c +++ b/hw/vmware_vga.c @@ -67,6 +67,11 @@ struct

[Qemu-devel] [PATCH 3/6] Make sure to enable dirty log tracking for VMware VGA

From: Anthony Liguori aligu...@us.ibm.com This is needed for VMware VGA to work properly under KVM. Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- hw/vmware_vga.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c index

[Qemu-devel] [PATCH 4/6] Fix VMware VGA depth computation

From: Anthony Liguori aligu...@us.ibm.com VMware VGA requires that the depth presented to the guest is the same as the DisplaySurface that it renders to. This is because it performs a very simple memcpy() to blit from one surface to another. We currently hardcode a 24-bit depth. The surface

[Qemu-devel] [PATCH 6/6] vmware: increase cursor buffer size.

From: Dave Airlie airl...@linux.ie The cursor pixmap size we calculate later ends up being 4096 dwords long by the looks of it. This boots an F12 LiveCD now. Signed-off-by: Dave Airlie airl...@linux.ie --- hw/vmware_vga.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[Qemu-devel] [PATCH 5/6] VMware VGA: Only enable dirty log tracking when fifo is disabled

the guest. Rebased-by: Dave Airlie airl...@redhat.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- hw/vga.c| 22 ++ hw/vga_int.h|2 ++ hw/vmware_vga.c | 16 3 files changed, 36 insertions(+), 4 deletions(-) diff --git a/hw/vga.c b

Re: [Qemu-devel] [PATCH 7/8] virtio-vga: v1

On Fri, Dec 6, 2013 at 6:58 PM, Dave Airlie airl...@gmail.com wrote: On Fri, Dec 6, 2013 at 6:24 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, Now the advice given was to have virtio-vga wrap virtio-gpu-base but from what I can see it really can't. Since it needs to act and look like

Re: [Qemu-devel] input, virtio-vga multihead -- current state

On Thu, Jan 30, 2014 at 2:28 AM, Gerd Hoffmann kra...@redhat.com wrote: * Didn't came very far in testing. Guest kernel just says: [ 50.712897] [drm] got -2147483647 outputs I've used http://cgit.freedesktop.org/~airlied/linux/log/?h=virtio-vga Switched to virtio-vga-3d branch

Re: [Qemu-devel] [Bug 788734] Re: vmwgfx does not work in Linux guest in kvm

On Sun, Mar 16, 2014 at 2:09 PM, Andrew Engelbrecht 788...@bugs.launchpad.net wrote: *** This bug is a duplicate of bug 1037606 *** https://bugs.launchpad.net/bugs/1037606 i am also having this problem on amd64 debian sid. using qemu verion 1.7.0+dfsg-5. on the guest system, i'm also

Re: [Qemu-devel] [PULL 7/7] gtk: Don't warp absolute pointer

On Thu, Mar 13, 2014 at 8:46 PM, Gerd Hoffmann kra...@redhat.com wrote: From: Cole Robinson crobi...@redhat.com Wierd I wrote and submitted these months ago, and they were promptly ignored, Glad you had to find bugs all over again an reinvent the wheel, Dave. This matches the behavior of

Re: [Qemu-devel] [PATCH 3/4] virtio-gpu: v0.3 of the virtio based GPU code.

On Thu, Mar 13, 2014 at 8:40 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 12/03/2014 21:26, Michael S. Tsirkin ha scritto: +Event queue: +The only current event passed is a message to denote the host +wants to update the layout of the screens. It contains the same +info as the response to

Re: [Qemu-devel] [PATCH 3/4] virtio-gpu: v0.3 of the virtio based GPU code.

On Mon, Mar 17, 2014 at 2:36 PM, Dave Airlie airl...@gmail.com wrote: On Thu, Mar 13, 2014 at 8:40 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 12/03/2014 21:26, Michael S. Tsirkin ha scritto: +Event queue: +The only current event passed is a message to denote the host +wants to update

[Qemu-devel] virtio device error reporting best practice?

So I'm looking at how best to do virtio gpu device error reporting, and how to deal with illegal stuff, I've two levels of errors I want to support, a) unrecoverable or bad guest kernel programming errors, b) per 3D context errors from the renderer backend, (b) I can easily report in an event

Re: [Qemu-devel] multihead multiseat in qemu

On Fri, Mar 21, 2014 at 11:27 PM, Gerd Hoffmann kra...@redhat.com wrote: Hi, I'm thinking about how to handle multihead and multiseat in qemu best. On multihead: Mouse in virtual machines works best with absolute coordinates, and the way this is done today is to assign a (virtual) usb

[Qemu-devel] updated virtio-gpu code

Hey, I've pushed a new version of the unaccelerated virtio-gpu code to my repo git://git.freedesktop.org/~airlied/qemu virtio-gpu this is Gerd vga-wip branch, with the virtgpu_hw file moved, removing the event queue and a config space added with a events_read, events_clear u32. I've also

Re: [Qemu-devel] updated virtio-gpu code

Just out of interest, with sdl and remote-viewer I seem to get 2 displays, one for the VGA time, and a separate one for the driver loaded, any ideas why? Ah this seems to be an artefact of my libvirt xml which demands I add a non-virtio vga device, thanks strict parser! Dave.

Re: [Qemu-devel] [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

Can the host refuse due to lack of resources? Yes. virtgpu_ctrl_hdr.type in the response will be set to VIRTGPU_RESP_ERR_* then. Current implementation does that only on malloc() failure, there is no accounting (yet) to limit the amout of memory the guest is allowed to allocate. We do

Re: [Qemu-devel] [virtio-dev] [PATCH 0/2] virtio-gpu: hardware specification

-wip https://www.kraxel.org/cgit/linux/log/?h=virtio-gpu-rebase The qemu patches are in a reasonable state. The linux kernel patches are not cleaned up yet, you probably want to look at the final tree only. Work has been done by Dave Airlie airl...@redhat.com and me. The authorship info

Re: [Qemu-devel] [virtio-dev] Re: [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt

On 14 September 2014 19:16, Michael S. Tsirkin m...@redhat.com wrote: On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann kra...@redhat.com --- docs/specs/virtio-gpu.txt | 165 ++ 1 file changed, 165

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

Triggered by the framebuffer endian issues we have with stdvga I've started to check where we stand with virtio-gpu and whenever we have to fix something in the virtio protocol before setting in stone with the upstream merge. Let me start by saying its not that I don't care about endianness,

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

On 30 September 2014 17:55, Gerd Hoffmann kra...@redhat.com wrote: On Di, 2014-09-30 at 10:27 +1000, Dave Airlie wrote: Triggered by the framebuffer endian issues we have with stdvga I've started to check where we stand with virtio-gpu and whenever we have to fix something in the virtio

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

On 15 October 2014 20:05, Gerd Hoffmann kra...@redhat.com wrote: Hi, +/* VIRTIO_GPU_RESP_OK_DISPLAY_INFO */ +#define VIRTIO_GPU_MAX_SCANOUTS 16 +struct virtio_gpu_resp_display_info { +struct virtio_gpu_ctrl_hdr hdr; +struct virtio_gpu_display_one { +uint32_t enabled; +

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file

Lets try to get away with 32bpp only in 2d mode then. bochsdrm likewise supports 32bpp only and I yet have to see a request for 16bpp or even 8bpp support. I think we should probably move a few more formats from the 3D side into the 2D side, so we can have the guests just pick the LE

Re: [Qemu-devel] [RfC PATCH 06/15] virtio-gpu/2d: add virtio gpu core code

But one non-formal question: As far as I understood virtio-gpu's mode of operation from this patch, it looks like there is one resource per scanout, and that resource is basically the whole screen (which can be updated partially). If that is the case, what do we gain from being able to

Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update

On 15 September 2015 at 07:14, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > Hi > > On Mon, Sep 14, 2015 at 11:08 PM, Dave Airlie <airl...@gmail.com> wrote: >> Currently the kernel driver does this: >> >> ret = virtio_gpu_cmd_transfer_to_ho

Re: [Qemu-devel] virtio-gpu: cursor update not in sync with resource update

On 15 September 2015 at 01:17, Marc-André Lureau wrote: > Hi > > On Mon, Sep 14, 2015 at 4:06 PM, Gerd Hoffmann wrote: >> The guest can upload different cursors and then switch between them >> without re-uploading and therefore without ctrl queue

Re: [Qemu-devel] [RFC PATCH] libcacard: move it to a standalone project

On 15 September 2015 at 23:37, Paolo Bonzini wrote: > On 15/09/2015 15:28, Daniel P. Berrange wrote: >> I have looked through the new libcacard git repository you created >> from QEMU history, and reviewed the extra patches you added on top >> for the build system and it all

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 18 January 2016 at 19:54, Gerd Hoffmann wrote: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 21 January 2016 at 19:05, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 21/01/2016 09:44, Dave Airlie wrote: >> I've hacked on this before, but only with SDL and it was pretty dirty, >> and it gave a fairly decent >> speed up. >> >> My thought

Re: [Qemu-devel] RFC: running the user interface in a thread ...

On 22 January 2016 at 16:59, Gerd Hoffmann wrote: > Hi, > >> In theory Mesa could help here, but GL isn't thread friendly at all, >> so it probably won't help in the virgl >> case even if it did. Since most GL apps compile a shader and block on >> using it straight away doing

[Qemu-devel] [PATCH] virtio-gpu-3d: add support for second capability set (v2)

From: Dave Airlie <airl...@redhat.com> Due to a kernel bug we can never increase the size of capability set 1, so introduce a new capability set in parallel, old userspace will continue to use the old set, new userspace will start using the new one when it detects a fixed kernel. v2: don

  1   2   >