OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH] transitional issues: add new IDs for all devices


On Mon, Oct 07, 2013 at 02:00:55PM +0200, Cornelia Huck wrote:
> On Mon, 7 Oct 2013 13:03:12 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > By the way, I looked at ccw. It seems to use this field
> > for device ID:
> > 
> > struct ccw_device_id {
> >         __u16   match_flags;    /* which fields to match against */
> > 
> >         __u16   cu_type;        /* control unit type     */
> >         __u16   dev_type;       /* device type           */
> >         __u8    cu_model;       /* control unit model    */
> >         __u8    dev_model;      /* device model          */
> > 
> >         kernel_ulong_t driver_info;
> > };
> > 
> > and
> > 
> >        dev_set_drvdata(&cdev->dev, vcdev);
> >        vcdev->vdev.id.vendor = cdev->id.cu_type;
> >        vcdev->vdev.id.device = cdev->id.cu_model;
> > 
> > 
> > That's broken: we'll run out of an 8 bit field
> > and we'll have problems.
> 
> Well, I did not anticipate the device number exceeding 8 bit...
> 
> > 
> > How about we put device id in dev_type instead?
> > 
> > We can use cu_type kind of like a revision field:
> > any value 0-10 is for transitional devices,
> > value 11 and up is for non transitional devices.
> 
> The thing I don't like about this is that we end up mixing control unit
> information (the cu_ fields) with device information (the dev_ fields).
> Conceptionally, I think of the virtio proxy device of something akin to
> a traditional control unit of a certain type (0x3832 == virtio-ccw) and
> a certain model (blk, net, ...). I did not provide a device since what
> I see as a 'device' (virtio-blk, virtio-net, ...) is not a device in
> the s390 channel sense (it doesn't talk ccw, only the 'control unit'
> does). If a 'device' would suddenly appear for the same control unit
> type, it would look all weird to me.
> 

I see virtio as an internal implementation detail
of the device.
For example, virtio pci devices are regular pci devices -
not a controller with a virtio bus.

Generally a "bus" or "controller" with always a single device
behind it always looks like over-engineering to me ...

> If we can't handle this with an extra ccw for the revision type, I'd
> vote for a new control unit type (which we'd have to reserve
> internally) and keeping the model at device number - 0x100. If this
> wouldn't work, we could have a fixed control unit model with this new
> type and encode the device number in the device type. Still a bit odd,
> but less odd than when keeping the control unit type.

Would all this need host kernel changes in kvm?
It's been a while since I looked at kvm s390.

-- 
MST


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]