qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other o


From: Avi Kivity
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Date: Mon, 30 Jul 2012 17:36:05 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/30/2012 05:29 PM, Anthony Liguori wrote:
> Avi Kivity <address@hidden> 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
>>> standard transport that the rest of our PV devices use.
>>
>> The drm drivers for the current model are needed anyway; so moving to
>> virtio is extra effort, not an alternative.
> 
> This is just a point in time statement.  If we were serious about using
> virtio then we could quickly introduce a virtio transport and only
> target the DRM drivers at the virtio transport.

That doesn't help all the deployed hypervisors out there.  IMO we're
mature enough, and the difference doesn't warrant a new interface.

>> Note virtio doesn't support mapping framebuffers yet
> 
> Yes.  I haven't seen a good proposal yet on how to handle this.  I think
> this is the main problem to solve.

It doesn't seem to be such a huge problem, though it does turn virtio
into a respec'ed PCI.

> 
>> or the entire vga compatibility stuff
> 
> This is actually independent of virtio.  A virtio-pci device could
> expose it's class code as a VGA adapter and also handle I/O accesses for
> the legacy region.  This is strictly a PC-ism.

We have to share the BAR space with VGA; not a huge problem.


-- 
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]