qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v4 1/3] Mediated device Core driver


From: Neo Jia
Subject: Re: [Qemu-devel] [RFC PATCH v4 1/3] Mediated device Core driver
Date: Sun, 5 Jun 2016 23:27:42 -0700
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Jun 06, 2016 at 02:01:48PM +0800, Dong Jia wrote:
> On Mon, 6 Jun 2016 10:57:49 +0530
> Kirti Wankhede <address@hidden> wrote:
> 
> > 
> > 
> > On 6/3/2016 2:27 PM, Dong Jia wrote:
> > > On Wed, 25 May 2016 01:28:15 +0530
> > > Kirti Wankhede <address@hidden> wrote:
> > > 
> > > 
> > > ...snip...
> > > 
> > >> +struct phy_device_ops {
> > >> +        struct module   *owner;
> > >> +        const struct attribute_group **dev_attr_groups;
> > >> +        const struct attribute_group **mdev_attr_groups;
> > >> +
> > >> +        int     (*supported_config)(struct device *dev, char *config);
> > >> +        int     (*create)(struct device *dev, uuid_le uuid,
> > >> +                          uint32_t instance, char *mdev_params);
> > >> +        int     (*destroy)(struct device *dev, uuid_le uuid,
> > >> +                           uint32_t instance);
> > >> +        int     (*start)(uuid_le uuid);
> > >> +        int     (*shutdown)(uuid_le uuid);
> > >> +        ssize_t (*read)(struct mdev_device *vdev, char *buf, size_t 
> > >> count,
> > >> +                        enum mdev_emul_space address_space, loff_t pos);
> > >> +        ssize_t (*write)(struct mdev_device *vdev, char *buf, size_t 
> > >> count,
> > >> +                         enum mdev_emul_space address_space, loff_t 
> > >> pos);
> > >> +        int     (*set_irqs)(struct mdev_device *vdev, uint32_t flags,
> > >> +                            unsigned int index, unsigned int start,
> > >> +                            unsigned int count, void *data);
> > >> +        int     (*get_region_info)(struct mdev_device *vdev, int 
> > >> region_index,
> > >> +                                 struct pci_region_info *region_info);
> > >> +        int     (*validate_map_request)(struct mdev_device *vdev,
> > >> +                                        unsigned long virtaddr,
> > >> +                                        unsigned long *pfn, unsigned 
> > >> long *size,
> > >> +                                        pgprot_t *prot);
> > >> +};
> > > 
> > > Dear Kirti:
> > > 
> > > When I rebased my vfio-ccw patches on this series, I found I need an
> > > extra 'ioctl' callback in phy_device_ops.
> > > 
> > 
> > Thanks for taking closer look. As per my knowledge ccw is not PCI
> > device, right? Correct me if I'm wrong.
> Dear Kirti:
> 
> You are right. CCW is different to PCI. The official term is 'Channel
> I/O device'. They use 'Channels' (co-processors) and CCWs (channel
> command words) to handle I/O operations.
> 
> > I'm curious to know. Are you planning to write a driver (vfio-mccw) for
> > mediated ccw device?
> I wrote two drivers:
> 1. A vfio-pccw driver for the physical ccw device, which will reigister
> the device and callbacks to mdev framework. With this, I could create
> a mediated ccw device for the physical one then.
> 2. A vfio-mccw driver for the mediated ccw device, which will add
> itself to a vfio_group, mimiced what vfio-mpci did.
> 
> The problem is, vfio-mccw need to implement new ioctls besides the
> existing ones (VFIO_DEVICE_GET_INFO, etc). And these ioctls really need
> the physical device help to handle.

Hi Dong,

Could you please help us understand a bit more about the new VFIO ioctl? Since 
it is
a new ioctl it is send down by QEMU in this case right? More details?

Thanks,
Neo

> 
> > 
> > Thanks,
> > Kirti
> > 
> > > The ccw physical device only supports one ccw mediated device. And I
> > > have two new ioctl commands for the ccw mediated device. One is 
> > > to hot-reset the resource in the physical device that allocated for
> > > the mediated device, the other is to do an I/O instruction translation
> > > and perform an I/O operation on the physical device. I found the
> > > existing callbacks could not meet my requirements.
> > > 
> > > Something like the following would be fine for my case:
> > >   int (*ioctl)(struct mdev_device *vdev,
> > >                unsigned int cmd,
> > >                unsigned long arg);
> > > 
> > > What do you think about this?
> > > 
> > > --------
> > > Dong Jia
> > > 
> > 
> 
> --------
> Dong Jia
> 



reply via email to

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