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

[Alexander Graf]

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

> On Mon, Jul 19, 2010 at 11:13:38AM +0200, Alexander Graf wrote:
>> 
>> 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?
>> 
> Vcpu executes "in %ax". Next instruction is executed 6 seconds later.
> All timers that should have been processed during this time fire at the
> same moment triggering all kind of timeouts. Think about watchdog that
> should be written into every two seconds otherwise it does reset.

That's a hypervisor implementation detail! If we want to go synchronously, we 
do. If something breaks, we don't. Doing it synchronously simpllifies things a 
lot. And we're talking about a device that's only used before the OS kicks in. 
There's no use in pretending we're running a watchdog there.

> 
>>> 
>>>>> 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.
>> 
> The virtio-blk is entirely in seabios and does not use pxe at all!

So it uses even more framework :). The linuxboot stuff is completely separate 
in its very own option rom.

Alex