"Michael S. Tsirkin" writes:
> On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote:
>> Rusty Russell writes:
>>
>> > Gerd Hoffmann writes:
>> >> So how about this:
>> >>
>> >> (1) Add a vendor specific pci capability for new-style virtio.
>> >> Specifies the pci bar used for new
Rusty Russell writes:
> Jamie Lokier writes:
>
>> Rusty Russell wrote:
>>> I don't think it'll be that bad; reset clears the device to unknown,
>>> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
>>> unknown->modern mode, and anything else is bad (I prefer being strict so
>>> we
On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote:
> Rusty Russell writes:
>
> > Gerd Hoffmann writes:
> >> So how about this:
> >>
> >> (1) Add a vendor specific pci capability for new-style virtio.
> >> Specifies the pci bar used for new-style virtio registers.
> >> Guest
Rusty Russell writes:
> Gerd Hoffmann writes:
>> So how about this:
>>
>> (1) Add a vendor specific pci capability for new-style virtio.
>> Specifies the pci bar used for new-style virtio registers.
>> Guests can use it to figure whenever new-style virtio is
>> supported and to map t
On Wed, Oct 10, 2012 at 02:14:11PM +1030, Rusty Russell wrote:
> > See above. A guest could happily just use BAR1/BAR2 and completely
> > ignore BAR0 provided that BAR1/BAR2 are present.
>
> But x86 guests want BAR0 because IO space is faster than MMIO. Right?
Or to be a bit more precise, ATM o
Anthony Liguori writes:
> Rusty Russell writes:
>
>> Anthony Liguori writes:
>>> We'll never remove legacy so we shouldn't plan on it. There are
>>> literally hundreds of thousands of VMs out there with the current virtio
>>> drivers installed in them. We'll be supporting them for a very, very
Gerd Hoffmann writes:
> So how about this:
>
> (1) Add a vendor specific pci capability for new-style virtio.
> Specifies the pci bar used for new-style virtio registers.
> Guests can use it to figure whenever new-style virtio is
> supported and to map the correct bar (which will proba
Jamie Lokier writes:
> Rusty Russell wrote:
>> I don't think it'll be that bad; reset clears the device to unknown,
>> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
>> unknown->modern mode, and anything else is bad (I prefer being strict so
>> we catch bad implementations from
On Tue, Oct 09, 2012 at 10:26:12AM +1030, Rusty Russell wrote:
> Anthony Liguori writes:
> > Gerd Hoffmann writes:
> >
> >> Hi,
> >>
> So we could have for virtio something like this:
>
> Capabilities: [??] virtio-regs:
> legacy: BAR=0 offset=0
>
Rusty Russell wrote:
> I don't think it'll be that bad; reset clears the device to unknown,
> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
> unknown->modern mode, and anything else is bad (I prefer being strict so
> we catch bad implementations from the beginning).
Will that w
Hi,
>> Why use two bars for this? You can put them into one mmio bar, together
>> with the msi-x vector table and PBA. Of course a pci capability
>> describing the location is helpful for that ;)
>
> You don't need a capability. You can also just add a "config offset"
> field to the register
Gerd Hoffmann writes:
> Hi,
>
>>> Well, we also want to clean up the registers, so how about:
>>>
>>> BAR0: legacy, as is. If you access this, don't use the others.
>
> Ok.
>
>>> BAR1: new format virtio-pci layout. If you use this, don't use BAR0.
>>> BAR2: virtio-cfg. If you use this, don't
Avi Kivity writes:
> On 10/09/2012 05:16 AM, Rusty Russell wrote:
>> Anthony Liguori writes:
>>> We'll never remove legacy so we shouldn't plan on it. There are
>>> literally hundreds of thousands of VMs out there with the current virtio
>>> drivers installed in them. We'll be supporting them
Rusty Russell writes:
> Anthony Liguori writes:
>> We'll never remove legacy so we shouldn't plan on it. There are
>> literally hundreds of thousands of VMs out there with the current virtio
>> drivers installed in them. We'll be supporting them for a very, very
>> long time :-)
>
> You will b
On 10/09/2012 05:16 AM, Rusty Russell wrote:
> Anthony Liguori writes:
>> We'll never remove legacy so we shouldn't plan on it. There are
>> literally hundreds of thousands of VMs out there with the current virtio
>> drivers installed in them. We'll be supporting them for a very, very
>> long ti
Hi,
>> Well, we also want to clean up the registers, so how about:
>>
>> BAR0: legacy, as is. If you access this, don't use the others.
Ok.
>> BAR1: new format virtio-pci layout. If you use this, don't use BAR0.
>> BAR2: virtio-cfg. If you use this, don't use BAR0.
Why use two bars for thi
Anthony Liguori writes:
> We'll never remove legacy so we shouldn't plan on it. There are
> literally hundreds of thousands of VMs out there with the current virtio
> drivers installed in them. We'll be supporting them for a very, very
> long time :-)
You will be supporting this for qemu on x86
Rusty Russell writes:
> Anthony Liguori writes:
>> Gerd Hoffmann writes:
>>
>>> Hi,
>>>
> So we could have for virtio something like this:
>
> Capabilities: [??] virtio-regs:
> legacy: BAR=0 offset=0
> virtio-pci: BAR=1 offset=1000
>
Anthony Liguori writes:
> Gerd Hoffmann writes:
>
>> Hi,
>>
So we could have for virtio something like this:
Capabilities: [??] virtio-regs:
legacy: BAR=0 offset=0
virtio-pci: BAR=1 offset=1000
virtio-cfg: BAR
Gerd Hoffmann writes:
> Hi,
>
>>> So we could have for virtio something like this:
>>>
>>> Capabilities: [??] virtio-regs:
>>> legacy: BAR=0 offset=0
>>> virtio-pci: BAR=1 offset=1000
>>> virtio-cfg: BAR=1 offset=1800
>>
>> This would be
Hi,
>> So we could have for virtio something like this:
>>
>> Capabilities: [??] virtio-regs:
>> legacy: BAR=0 offset=0
>> virtio-pci: BAR=1 offset=1000
>> virtio-cfg: BAR=1 offset=1800
>
> This would be a vendor specific PCI capability so
Gerd Hoffmann writes:
> Hi,
>
>> But I think we could solve this in a different way. I think we could
>> just move the virtio configuration space to BAR1 by using a transport
>> feature bit.
>
> Why hard-code stuff?
>
> I think it makes alot of sense to have a capability simliar to msi-x
> whi
Hi,
> But I think we could solve this in a different way. I think we could
> just move the virtio configuration space to BAR1 by using a transport
> feature bit.
Why hard-code stuff?
I think it makes alot of sense to have a capability simliar to msi-x
which simply specifies bar and offset of
Rusty Russell writes:
> (Topic updated, cc's trimmed).
>
> Anthony Liguori writes:
>> Rusty Russell writes:
>>> 4) The only significant change to the spec is that we use PCI
>>>capabilities, so we can have infinite feature bits.
>>>(see
>>> http://lists.linuxfoundation.org/pipermail/vi
24 matches
Mail list logo
