qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) dev


From: Alexander Graf
Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device
Date: Mon, 19 Jul 2010 11:13:38 +0200

On 19.07.2010, at 11:10, Gleb Natapov wrote:

> On Mon, Jul 19, 2010 at 11:02:54AM +0200, Alexander Graf wrote:
>> 
>> On 19.07.2010, at 11:00, Gleb Natapov wrote:
>> 
>>> On Mon, Jul 19, 2010 at 10:54:43AM +0200, Alexander Graf wrote:
>>>> 
>>>> On 19.07.2010, at 10:48, Gleb Natapov wrote:
>>>> 
>>>>> 
>>>>>> Were there DMA capable devices back in ISA times? There must be. If so, 
>>>>>> we can just take a look at what they do and do it similarly. Bus 
>>>>>> mastering was a new thing for PCI, right?
>>>>>> 
>>>>> I think IDE can be considered DMA capable ISA device, no? At least
>>>>> it works by writing to PIO ports and getting result into memory, but
>>>>> with interrupts and status bits and everything that real device should
>>>>> have. On board DMA engine is also ISA device. 
>>>> 
>>>> We could define our device to be polling. So all we need is a status bit 
>>>> that the guest sets when it starts the DMA and the device unsets when the 
>>>> DMA is done. In our case that should be immediate, because the PIO invokes 
>>>> the full code paths, but it would look more like a real device, no?
>>>> 
>>> This is better, but it shouldn't be synchronous. Kernel and initrd are
>>> on disk so why not setup aio and read them from io thread allowing vcpu
>>> thread immediately return to guest mode to process interrupts.
>> 
>> That would work with the above described device model. If we're going 
>> synchronous or asynchronous would become an implementation detail.
>> 
> If vcpu thread will sleep for too much time without processing events we can 
> see strange timeouts in a guest.

I don't think I understand what you mean?

> 
>>> Or why
>>> not use virtio-serial while we are at it? After all virtio-serial is
>>> there to allow host and guest communication.
>> 
>> Because virtio-serial needs us to set up the full virtio-pci stack. That's 
>> too much to mess with in an option rom IMHO.
>> 
> We already do it for virtio-blk. Read only support is very small in
> LOC there. Don't know about virtio-serial protocol.

The virtio-blk model uses the whole pxe framework. For our in-tree option roms 
we're trying to be simple. And I'd like to keep it that way. I really don't 
want to add PCI enumeration and BAR setup to that code.


Alex




reply via email to

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