Hi,
>> Maybe the guest driver places the qxl commands in native endian instead
>> of big endian into memory?
>
> The guest drivers places the commands in the memory in its native
> endianess. That why the device only works when guest/host has the same
> endianess. That's sanit-checks doesn't fa
On Wed, Aug 8, 2012 at 3:18 AM, Gerd Hoffmann wrote:
> Hi,
>
The only thing
its missing is to fix the endianess for server/client handshaking.
>>>
>>> What exactly do you mean here?
>>
>> Well that are negotiation messages configuring each channel, its
>> capabilities, encryption keys
Hi,
>>> The only thing
>>> its missing is to fix the endianess for server/client handshaking.
>>
>> What exactly do you mean here?
>
> Well that are negotiation messages configuring each channel, its
> capabilities, encryption keys , etc. After this negotiation, the
> server start to send SPICE
>On Tue, Aug 7, 2012 at 11:07 AM, Gerd Hoffmann wrote:
>
> On 08/07/12 15:05, Erlon Cruz wrote:
> > Em 07/08/2012 05:01, "Gerd Hoffmann" escreveu:
> >>
> >> Hi,
> >>
> >>> Why not make libspice mandatory?
> >>
> >> spice needs to build and run on alot of platforms where it doesn't run
> >> toda
On 08/07/12 15:05, Erlon Cruz wrote:
> Em 07/08/2012 05:01, "Gerd Hoffmann" escreveu:
>>
>> Hi,
>>
>>> Why not make libspice mandatory?
>>
>> spice needs to build and run on alot of platforms where it doesn't run
>> today. So it isn't an option right now. Which doesn't imply it will
>> never h
Em 07/08/2012 05:01, "Gerd Hoffmann" escreveu:
>
> Hi,
>
> > Why not make libspice mandatory?
>
> spice needs to build and run on alot of platforms where it doesn't run
> today. So it isn't an option right now. Which doesn't imply it will
> never happen, but spice certainly needs some work bef
Hi,
> Why not make libspice mandatory?
spice needs to build and run on alot of platforms where it doesn't run
today. So it isn't an option right now. Which doesn't imply it will
never happen, but spice certainly needs some work before we can
seriously discuss that.
Make spice work on bigendi
On Fri, Aug 03, 2012 at 08:41:36AM -0500, Anthony Liguori wrote:
> Alon Levy writes:
>
> > On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote:
> >> Andreas Färber writes:
> >>
> >> > Am 30.07.2012 18:19, schrieb Alon Levy:
> >> >> On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin
On Tue, 2012-08-07 at 07:30 +0200, Gerd Hoffmann wrote:
> On 08/06/12 23:16, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-08-06 at 15:20 +0200, Gerd Hoffmann wrote:
> >> There are discussions about re-doing the guest/host interface (command
> >> rings etc) now and then, by adding a qxl2 device (o
On 08/06/12 23:16, Benjamin Herrenschmidt wrote:
> On Mon, 2012-08-06 at 15:20 +0200, Gerd Hoffmann wrote:
>> There are discussions about re-doing the guest/host interface (command
>> rings etc) now and then, by adding a qxl2 device (or maybe even extend
>> stdvga), dropping a bunch of backward com
On Mon, 2012-08-06 at 15:20 +0200, Gerd Hoffmann wrote:
> There are discussions about re-doing the guest/host interface (command
> rings etc) now and then, by adding a qxl2 device (or maybe even extend
> stdvga), dropping a bunch of backward compatibility stuff in qxl.c.
>
> Sending the spice comm
On Mon, 2012-08-06 at 16:02 +0200, Gerd Hoffmann wrote:
>
> A vbe rom isn't a big deal. You probably want support the 0x01CE and
> 0x01CF ports (on x86) so the vgabios running in real mode can easily
> reach the bochs interface registers without a protected mode round
> trip
> for mmio access.
>
Gerd Hoffmann writes:
> Hi,
>
>> QXL has a lot of short comings. Here's a short list:
>>
>> - It's 100% PC centric. It requires PCI and is completely oblivious to
>> endianness.
>
> No. The endianess is actually clearly defined. It's little endian for
> both guest/host interface (aka qxl
Hi,
> The latter sounds like a better long term approach, however it lacks
> backward compat with qemu-vga, but I doubt it's a big deal especially if
> we provide a working VBE ROM for x86.
A vbe rom isn't a big deal. You probably want support the 0x01CE and
0x01CF ports (on x86) so the vgabio
Hi,
> QXL has a lot of short comings. Here's a short list:
>
> - It's 100% PC centric. It requires PCI and is completely oblivious to
> endianness.
No. The endianess is actually clearly defined. It's little endian for
both guest/host interface (aka qxl) and the network protocol.
So it i
Hi,
Hi,
> Minor improvements to stdvga actual help qxl (presumably). qxl still
> provides a vga interface which is used when guest drivers aren't
> available.
>
> It's not clear to me why it doesn't enable VBE but presumably if it did,
> then accelerations could be mapped through VBE.
QXL a
On 07/30/12 14:08, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
>> Let's balkanize some more then?
>>
>> No, qxl is our paravirt vga, we should improve it instead of spawning
>> new ones (which will be horrible in the eyes of the next person to look
>> at the
Alon Levy writes:
> On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote:
>> Andreas Färber writes:
>>
>> > Am 30.07.2012 18:19, schrieb Alon Levy:
>> >> On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
>> >>> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote
On Wed, Aug 01, 2012 at 02:22:37PM -0500, Anthony Liguori wrote:
> Andreas Färber writes:
>
> > Am 30.07.2012 18:19, schrieb Alon Levy:
> >> On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
> >>> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
> >>>
> [...] why no
Am 30.07.2012 18:01, schrieb Anthony Liguori:
> I'm not saying that we should remove qxl.c from QEMU. We can continue
> to support that ABI forever.
>
> But there's a lot of value in a new graphics interface that uses virtio
> and negotiates support for the Spice protocol. That way, if QEMU
> do
Andreas Färber writes:
> Am 30.07.2012 18:19, schrieb Alon Levy:
>> On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
>>> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
>>>
[...] why not go all the way to qxl?
That will give you better graphics performan
Am 30.07.2012 18:19, schrieb Alon Levy:
> On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
>>
>>> [...] why not go all the way to qxl?
>>>
>>> That will give you better graphics performance with no need to hack.
>>
>> We
On 07/31/2012 01:24 AM, Benjamin Herrenschmidt wrote:
>
> So Anthony listed a few, the transport being inconsistent with all our
> other paravirt model is also part of the problem, and the spice code
> base just hurts my eyes. The fact that it's essentially GDI centric
> makes it a non starter for
On Tue, 2012-07-31 at 18:44 +1000, ronnie sahlberg wrote:
>
> I use lots of guests that will never ever get virtio drivers.
> So for those guests, any work on making sure bog standard vga keeps
> working or even improving it
> gets two thumbs up from me!
So I've been essentially restarting my wor
On Mon, Jul 30, 2012 at 4:24 PM, Benjamin Herrenschmidt
wrote:
> So I got cirrus working on ppc with cirrusdrmfb...
>
> The fun part is that it works :-)
>
> Basically, the issue is that normally, for it to work, one would have to
> access the framebuffer using the appropriate aperture for byteswa
On Mon, Jul 30, 2012 at 09:29:01AM -0500, Anthony Liguori wrote:
> Avi Kivity writes:
>
> >>> Virtio makes sense for qxl, but for now we have the original pci model
> >>> which I don't see a reason why it can't work for ppc.
> >>
> >> I'm sure it can work for PPC given enough effort. But I thin
On Tue, Jul 31, 2012 at 08:24:23AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 18:24 +0200, Alon Levy wrote:
> > On Mon, Jul 30, 2012 at 10:08:07PM +1000, Benjamin Herrenschmidt wrote:
> > > On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
> > > > Let's balkanize some more then
On Mon, 2012-07-30 at 19:17 -0500, Anthony Liguori wrote:
> This is a detail of how Spice/QXL works. It is not a framebuffer
> protocol.
>
> Spice sends a series of rendering commands. It not rendering to a flat
> framebuffer but rather to window-like objects. It maintains a list of
> these co
On Tue, 2012-07-31 at 09:17 +0930, Rusty Russell wrote:
>
> Shared memory is an efficiency thing, not a requirement. If the
> virtio
> side-channel tells the device about the location of framebuffer
> changes, it could still be quite efficient.
But potentially tricky to get things like BIOSes wo
On Mon, 30 Jul 2012 11:01:20 -0500, Anthony Liguori
wrote:
> Avi Kivity writes:
> > It doesn't seem to be such a huge problem, though it does turn virtio
> > into a respec'ed PCI.
>
> Virtio was originally designed to be a DMA API (although not ABI). From
> a virtio-pci perspective, adding a l
Benjamin Herrenschmidt writes:
> On Mon, 2012-07-30 at 16:55 +0300, Avi Kivity wrote:
>> > The trouble is predicting which guests have drivers and which guests
>> > don't. Having a VGA model that could be enabled universally with good
>> > VBE support for guests without drivers would be a very n
On Mon, 2012-07-30 at 18:24 +0200, Alon Levy wrote:
> On Mon, Jul 30, 2012 at 10:08:07PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
> > > Let's balkanize some more then?
> > >
> > > No, qxl is our paravirt vga, we should improve it instead of spaw
On Mon, 2012-07-30 at 16:55 +0300, Avi Kivity wrote:
> > The trouble is predicting which guests have drivers and which guests
> > don't. Having a VGA model that could be enabled universally with good
> > VBE support for guests without drivers would be a very nice default
> > model.
>
> I agree.
Alon Levy writes:
> On Mon, Jul 30, 2012 at 10:08:07PM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
>> > Let's balkanize some more then?
>> >
>> > No, qxl is our paravirt vga, we should improve it instead of spawning
>> > new ones (which will be ho
On Mon, Jul 30, 2012 at 10:08:07PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
> > Let's balkanize some more then?
> >
> > No, qxl is our paravirt vga, we should improve it instead of spawning
> > new ones (which will be horrible in the eyes of the n
On Mon, Jul 30, 2012 at 09:54:27PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
>
> > > Right. Cirrus on ppc was used on PReP and Amiga for example though not
> > > many people really care about those platforms anymore. I'm not too
> > > worried at th
Avi Kivity writes:
> On 07/30/2012 05:29 PM, Anthony Liguori wrote:
>> Avi Kivity writes:
>>
> Virtio makes sense for qxl, but for now we have the original pci model
> which I don't see a reason why it can't work for ppc.
I'm sure it can work for PPC given enough effort. But
On Mon, Jul 30, 2012 at 3:30 PM, Peter Maydell wrote:
> On 30 July 2012 16:18, Blue Swirl wrote:
>> I think even this is not fully accurate description of the VGA
>> insanity, because if the host display happens to use BGR pixel format
>> instead of RGB, there may be more byte shuffling, but not
On 30 July 2012 16:18, Blue Swirl wrote:
> I think even this is not fully accurate description of the VGA
> insanity, because if the host display happens to use BGR pixel format
> instead of RGB, there may be more byte shuffling, but not in all
> cases: compare vga_draw_line24() to vga_draw_line32
On Mon, Jul 30, 2012 at 6:24 AM, Benjamin Herrenschmidt
wrote:
> So I got cirrus working on ppc with cirrusdrmfb...
>
> The fun part is that it works :-)
>
> Basically, the issue is that normally, for it to work, one would have to
> access the framebuffer using the appropriate aperture for byteswa
On 07/30/2012 05:29 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
Virtio makes sense for qxl, but for now we have the original pci model
which I don't see a reason why it can't work for ppc.
>>>
>>> I'm sure it can work for PPC given enough effort. But I think the
>>> question bec
Avi Kivity writes:
>>> Virtio makes sense for qxl, but for now we have the original pci model
>>> which I don't see a reason why it can't work for ppc.
>>
>> I'm sure it can work for PPC given enough effort. But I think the
>> question becomes, why not invest that effort in moving qxl to the
>>
On 07/30/2012 04:45 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> On 07/30/2012 04:18 PM, Anthony Liguori wrote:
>>> Avi Kivity writes:
>>>
On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote:
>>
>> >
>> > We can also make the fbdev/fbcon driver do the swapping in SW,
Avi Kivity writes:
> On 07/30/2012 04:18 PM, Anthony Liguori wrote:
>> Avi Kivity writes:
>>
>>> On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote:
>
> >
> > We can also make the fbdev/fbcon driver do the swapping in SW, but it's
> > a relatively unusual code path and I don
On 07/30/2012 04:18 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote:
>
> We can also make the fbdev/fbcon driver do the swapping in SW, but it's
> a relatively unusual code path and I don't think it works properly wit
Avi Kivity writes:
> On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote:
>>>
>>> >
>>> > We can also make the fbdev/fbcon driver do the swapping in SW, but it's
>>> > a relatively unusual code path and I don't think it works properly with
>>> > X, I don't think it can be made to work properly
On Mon, 2012-07-30 at 15:15 +0300, Avi Kivity wrote:
> > Something tells me that getting that spice/qxl gunk will be more than a
> > trivial effort (but I might be wrong) and I'm reluctant to start
> > committing effort on it since so far I yet have to see it being actually
> > picked up by people.
On 07/30/2012 03:08 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
>> Let's balkanize some more then?
>>
>> No, qxl is our paravirt vga, we should improve it instead of spawning
>> new ones (which will be horrible in the eyes of the next person to look
>>
On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
> Let's balkanize some more then?
>
> No, qxl is our paravirt vga, we should improve it instead of spawning
> new ones (which will be horrible in the eyes of the next person to look
> at them). You should also be getting the drm driver for free
On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote:
>>
>> >
>> > We can also make the fbdev/fbcon driver do the swapping in SW, but it's
>> > a relatively unusual code path and I don't think it works properly with
>> > X, I don't think it can be made to work properly with the generic X KMS
>> >
On Mon, 2012-07-30 at 14:25 +0300, Avi Kivity wrote:
> > Right. Cirrus on ppc was used on PReP and Amiga for example though not
> > many people really care about those platforms anymore. I'm not too
> > worried at this point with that possibility but we shall know about it.
>
> Emulating somethin
On 07/30/2012 02:20 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-30 at 13:08 +0300, Avi Kivity wrote:
>>
>> > So we end up with what is effectively a BE framebuffer thanks to qemu
>> > hard coding what it thinks the guest endian is (btw, this is quite
>> > busted in theory as well since PP
On Mon, 2012-07-30 at 13:08 +0300, Avi Kivity wrote:
>
> > So we end up with what is effectively a BE framebuffer thanks to qemu
> > hard coding what it thinks the guest endian is (btw, this is quite
> > busted in theory as well since PPC can be bi-endian for example).
> >
> > Anyways, it works
On 07/30/2012 09:24 AM, Benjamin Herrenschmidt wrote:
> So I got cirrus working on ppc with cirrusdrmfb...
>
> The fun part is that it works :-)
>
> Basically, the issue is that normally, for it to work, one would have to
> access the framebuffer using the appropriate aperture for byteswapping
>
So I got cirrus working on ppc with cirrusdrmfb...
The fun part is that it works :-)
Basically, the issue is that normally, for it to work, one would have to
access the framebuffer using the appropriate aperture for byteswapping
based on the bpp.
However, qemu doesn't emulate those apertures ...
55 matches
Mail list logo
