qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 0/2] fix virtio_blk serial pci config breakage


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: [PATCH 0/2] fix virtio_blk serial pci config breakage
Date: Tue, 29 Sep 2009 16:06:02 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Tue, Sep 29, 2009 at 08:55:20AM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Sep 29, 2009 at 09:22:53AM +0200, Avi Kivity wrote:
>>   
>>> On 09/29/2009 08:58 AM, Michael S. Tsirkin wrote:
>>>     
>>>> Using bar per feature we'll quickly run out of BARs.
>>>> We already use a BAR for MSI-X - let's add
>>>> ATA identity there?
>>>>          
>>> Mixing unrelated features will quickly cause confusion.
>>>     
>>
>> Note if we ever switch to 64 bit BARs, we'll only have 3 of these
>> available, so the ID would be using the last free one.
>> We can just as well plan ahead for when we'll add another feature?
>>
>> I agree fixed offsets are messy though.  I previously proposed storing
>> the offset to the identity data in an i/o register. This will let each
>> implementation lay out this data in an optimal manner, without
>> confusion.
>>   
>
> 1) There's no need to make the identity page separate from the config  
> space.  The real problem is the config space is too small.  We can fix  
> that without making any changes to virtio-blk by putting the config  
> space in a separate BAR.

I don't think it's such a good idea.  We want to keep exposing most of
config space in i/o bar because of backwards compatibility.  And we want
to keep datapath operations such as vq kicks, in i/o space.


> 2) Passing an ATA identity page is goofy.  We should just pass the  
> serial number and let Linux generate the identity page.  Just because  
> Linux requires this as it's user space interface, that doesn't mean that  
> other guests will (like Windows).  Instead of exposing an opaque blob,  
> we should expose the information we need in a structured way.
>
> Regards,
>
> Anthony Liguori




reply via email to

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