Gerd,
This seems to have passed the bots, but realised I hadn't cc'ed you.
Please pick it up whenever you get a chance.
Dave.
On 23 February 2018 at 12:38, Dave Airlie wrote:
> From: Dave Airlie
>
> Due to a kernel bug we can never increase the size of capability
> set
From: Dave Airlie
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't use a define
From: Dave Airlie
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't use a define
From: Dave Airlie
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't use a define
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 it
>> in a thread w
On 21 January 2016 at 19:05, Paolo Bonzini 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 thoughts are to use dat
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 little
> longer.
>
> op
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 looks sane to me. So t
On 15 September 2015 at 07:14, Marc-André Lureau
wrote:
> Hi
>
> On Mon, Sep 14, 2015 at 11:08 PM, Dave Airlie wrote:
>> Currently the kernel driver does this:
>>
>> ret = virtio_gpu_cmd_transfer_to_host_2d(vgdev,
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 updates. Thats
>> why they have an id in the firs
>
> 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 t
>
> 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
On 15 October 2014 20:05, Gerd Hoffmann 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;
>> +
On 30 September 2014 17:55, Gerd Hoffmann 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
>> >
> 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 endiannes
On 14 September 2014 19:16, Michael S. Tsirkin wrote:
> On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann
>> ---
>> docs/specs/virtio-gpu.txt | 165
>> ++
>> 1 file changed, 165 insertions(+)
>> create mod
www.kraxel.org/cgit/qemu/log/?h=rebase/vga-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
>> 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
>
> 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.
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 pushed
On Fri, Mar 21, 2014 at 11:27 PM, Gerd Hoffmann 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
> tablet to the
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 q
On Mon, Mar 17, 2014 at 2:36 PM, Dave Airlie wrote:
> On Thu, Mar 13, 2014 at 8:40 PM, Paolo Bonzini 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
On Thu, Mar 13, 2014 at 8:40 PM, Paolo Bonzini 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 VIR
On Thu, Mar 13, 2014 at 8:46 PM, Gerd Hoffmann wrote:
> From: Cole Robinson
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 SDL, and makes the mouse usable when
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
On Thu, Jan 30, 2014 at 2:28 AM, Gerd Hoffmann 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 -- that i
On Fri, Dec 6, 2013 at 6:58 PM, Dave Airlie wrote:
> On Fri, Dec 6, 2013 at 6:24 PM, Gerd Hoffmann 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
On Tue, Dec 17, 2013 at 8:12 AM, Stefan Weil wrote:
> Am 16.12.2013 11:48, schrieb Gerd Hoffmann:
>> From: Dave Airlie
>>
>> I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface.
>>
>> The biggest changes were in the input handling, w
On Thu, Dec 12, 2013 at 6:17 PM, Gerd Hoffmann 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 th
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 does
On Wed, Dec 11, 2013 at 12:35 AM, Gerd Hoffmann 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 the keybo
On Tue, Dec 10, 2013 at 2:05 PM, Dave Airlie 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.
>
From: Dave Airlie
Oh I forgot to fix these up previously.
Signed-off-by: Dave Airlie
---
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 7bf2fbb..28dcd1e 100644
--- a/hw/display
From: Dave Airlie
---
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 pci_std_vga_initfn
From: Dave Airlie
This is a virtio-vga device built on top of the virtio-gpu device.
Signed-off-by: Dave Airlie
---
Makefile | 2 +-
default-configs/x86_64-softmmu.mak | 1 +
hw/display/Makefile.objs | 1 +
hw/display/virtio-vga.c| 156
From: Dave Airlie
This just adds ctrl-alt-n to toggle head 1 on/off for testing and demo purposes.
Signed-off-by: Dave Airlie
---
ui/sdl2.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ui/sdl2.c b/ui/sdl2.c
index dd8cd2b..c52dcd9 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -522,6
From: Dave Airlie
this adds support for the callbacks from the console layer, when the gpu
changes the layouts.
Signed-off-by: Dave Airlie
---
ui/sdl2.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 2eb3e9c..dd8cd2b 100644
--- a/ui/sdl2.c
+++ b/ui
From: Dave Airlie
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
---
include/ui/console.h | 8 +++-
ui/console.c
From: Dave Airlie
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 that snuck in
Signed-off
From: Dave Airlie
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 compatible
From: Dave Airlie
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 from its own ones
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, hopefu
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.
From: Dave Airlie
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 warp.
Signe
From: Dave Airlie
If the guest asks for no cursor, switch gtk to using the null cursor.
Signed-off-by: Dave Airlie
---
ui/gtk.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index 2abf289..f60e66f 100644
--- a/ui/gtk.c
+++ b
On Mon, Dec 9, 2013 at 1:54 PM, Dave Airlie wrote:
> On Mon, Dec 9, 2013 at 10:49 AM, Dave Airlie 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 th
On Mon, Dec 9, 2013 at 10:49 AM, Dave Airlie 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
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.
On Fri, Dec 6, 2013 at 6:24 PM, Gerd Hoffmann 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 things a
On Thu, Nov 21, 2013 at 9:06 PM, Gerd Hoffmann wrote:
> On Do, 2013-11-21 at 13:12 +1000, Dave Airlie wrote:
>> On Wed, Nov 20, 2013 at 10:02 PM, Gerd Hoffmann wrote:
>> > On Mi, 2013-11-20 at 15:52 +1000, Dave Airlie wrote:
>> >> From: Dave Airlie
>> >&g
On Thu, Dec 5, 2013 at 6:52 PM, Gerd Hoffmann 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
>> > to
On Wed, Dec 4, 2013 at 6:23 PM, Gerd Hoffmann 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 vi
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 s
On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann 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.
>> > The
On Wed, Nov 20, 2013 at 10:02 PM, Gerd Hoffmann wrote:
> On Mi, 2013-11-20 at 15:52 +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> 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
On Thu, Nov 21, 2013 at 1:14 AM, Gerd Hoffmann 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 this
From: Dave Airlie
This is a virtio-vga device built on top of the virtio-gpu device.
Signed-off-by: Dave Airlie
---
Makefile | 2 +-
default-configs/x86_64-softmmu.mak | 1 +
hw/display/Makefile.objs | 1 +
hw/display/virtio-vga.c| 156
From: Dave Airlie
This is the basic virtio-gpu which is
multi-head capable,
ARGB cursor support,
unaccelerated.
Signed-off-by: Dave Airlie
---
default-configs/x86_64-softmmu.mak | 1 +
hw/display/Makefile.objs | 2 +
hw/display/virtgpu_hw.h| 225 ++
hw
From: Dave Airlie
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 on/off.
Signed
From: Dave Airlie
---
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 pci_std_vga_initfn
From: Dave Airlie
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 it to the list.
(may
From: Dave Airlie
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 compatible
From: Dave Airlie
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
---
include/ui/console.h | 8 +++-
ui/console.c
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 t
From: Dave Airlie
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 from its own ones
On Wed, Nov 20, 2013 at 3:17 PM, Dave Airlie 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
>> 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 c
On Tue, Nov 19, 2013 at 6:11 PM, Gerd Hoffmann 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
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 in
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 th
On Tue, Nov 12, 2013 at 8:32 AM, Alex Williamson
wrote:
> On Tue, 2013-11-12 at 07:55 +1000, Dave Airlie wrote:
>> On Tue, Nov 12, 2013 at 7:43 AM, Alex Williamson
>> wrote:
>> > When MSI is enabled on Nvidia GeForce cards the driver seems to
>> > acknowledge the
On Tue, Nov 12, 2013 at 7:43 AM, Alex Williamson
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. Without this, the devic
On Tue, Nov 12, 2013 at 12:07 AM, Anthony Liguori wrote:
>
> On Nov 11, 2013 1:10 AM, "Dave Airlie" wrote:
>>
>> On Mon, Nov 11, 2013 at 2:02 PM, Anthony Liguori
>> wrote:
>> > On Sun, Nov 10, 2013 at 3:15 PM, Dave Airlie wrote:
>> >> Fro
On Mon, Nov 11, 2013 at 2:02 PM, Anthony Liguori wrote:
> On Sun, Nov 10, 2013 at 3:15 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface.
>>
>> The biggest changes were in the
From: Dave Airlie
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 compatible
On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann 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 haven't
On Wed, Nov 6, 2013 at 6:42 AM, John Baboval 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.
>
> One of the majo
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==b
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 an
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 o
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) i
On Tue, Jul 9, 2013 at 10:35 AM, Dave Airlie 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
&
based-by: Dave Airlie
Signed-off-by: Anthony Liguori
---
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/hw/vga.c
index 5b0c55e..d05f1f9 100644
--- a/hw/
From: Dave Airlie
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
---
hw/vmware_vga.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/vmware_vga.c b/hw
From: Anthony Liguori
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 allocator for SDL may,
From: Anthony Liguori
This is needed for VMware VGA to work properly under KVM.
Signed-off-by: Anthony Liguori
---
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 07befc8..fcb6808 100644
--- a/hw/vmware_vga.c
+
From: Dave Airlie
---
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 vmsvga_state_s
screen.
This is the true root cause of VMware VGA not working correctly under KVM and
likely also an issue with some of the std-vga black screen issues too.
Cirrus does not enable VBE so it would not be a problem when using Cirrus.
Signed-off-by: Anthony Liguori
Rebased-by: Dave Airlie
---
hw
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 Liv
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
http://cgit.freedesktop.org/~airlied/qemu/log/?h=vmw
On Tue, Dec 15, 2009 at 12:28 AM, Anthony Liguori 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/q
On Mon, Dec 14, 2009 at 3:59 AM, Anthony Liguori 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
>>>
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.
On Sun, Dec 13, 2009 at 1:23 AM, Anthony Liguori wrote:
> Juan Quintela wrote:
>>
>> Dave Airlie wrote:
>>
>>>>>
>>>>> Current existing solutions in the area:
>>>>> a) VMware virtual graphics adapter - based on DX9, has an open
On Sun, Dec 13, 2009 at 5:28 AM, Anthony Liguori 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 giving to th
>>
>> 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)
http://vmware-svg
On Sat, Dec 12, 2009 at 1:31 PM, Anthony Liguori 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 compos
Oops gmail send this, silly laptop has a mind of its own sometimes.
On Sat, Dec 12, 2009 at 11:58 AM, Dave Airlie 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
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 D
1 - 100 of 103 matches
Mail list logo
