search for: ccws

...io-blk device used virtio-1, a virtio-balloon device legacy. One thing I noticed, though, is that I may need to think about virtio-ccw revision vs. virtio version again. As a device can refuse virtio-1 after the driver negotiated revision 1, we're operating a legacy device with (some) standard ccws. Probably not a big deal, as (a) both driver and device already have indicated that they support revision 1 which those ccws are tied to and (b) some legacy devices/drivers already support standard ccws (adapter interrupt support). I might want to clarify the standard a bit, let me think about that...

...__aligned(8); > > #define to_io_private(n) ((struct io_subchannel_private *) \ > @@ -115,6 +120,13 @@ enum cdev_todo { > #define FAKE_CMD_IRB 1 > #define FAKE_TM_IRB 2 > > +struct ccw_device_dma_area { > + struct senseid senseid; /* SenseID info */ > + struct ccw1 iccws[2]; /* ccws for SNID/SID/SPGID commands */ > + struct irb irb; /* device status */ > + struct pgid pgid[8]; /* path group IDs per chpid*/ Again, ccws, and blocks that will be written by the hypervisor, which makes sense as well. > +}; > + > struct ccw_device_private { > stru...

...trary device", perhaps?) > > What I mean is: this patch takes care of the core stuff, but any > particular device is likely to have to do more -- that is it ain't all > the cio devices support prot virt with this patch. For example > virtio-ccw needs to make sure that the ccws constituting the channel > programs, as well as the data pointed by the ccws is shared. If one > would want to make vfio-ccw DASD pass-through work under prot virt, one > would need to make sure, that everything that needs to be shared is > shared (data buffers, channel programs). >...

...trary device", perhaps?) > > What I mean is: this patch takes care of the core stuff, but any > particular device is likely to have to do more -- that is it ain't all > the cio devices support prot virt with this patch. For example > virtio-ccw needs to make sure that the ccws constituting the channel > programs, as well as the data pointed by the ccws is shared. If one > would want to make vfio-ccw DASD pass-through work under prot virt, one > would need to make sure, that everything that needs to be shared is > shared (data buffers, channel programs). >...

...ps?) > > > > What I mean is: this patch takes care of the core stuff, but any > > particular device is likely to have to do more -- that is it ain't all > > the cio devices support prot virt with this patch. For example > > virtio-ccw needs to make sure that the ccws constituting the channel > > programs, as well as the data pointed by the ccws is shared. If one > > would want to make vfio-ccw DASD pass-through work under prot virt, one > > would need to make sure, that everything that needs to be shared is > > shared (data buffers, chan...

...o you mean "every arbitrary device", perhaps?) What I mean is: this patch takes care of the core stuff, but any particular device is likely to have to do more -- that is it ain't all the cio devices support prot virt with this patch. For example virtio-ccw needs to make sure that the ccws constituting the channel programs, as well as the data pointed by the ccws is shared. If one would want to make vfio-ccw DASD pass-through work under prot virt, one would need to make sure, that everything that needs to be shared is shared (data buffers, channel programs). Does is clarify things?...

On Fri, 24 Oct 2014 00:42:20 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote: > > This patchset aims to get us some way to implement virtio-1 compliant > > and transitional devices in qemu. Branch available at > > > > git://github.com/cohuck/qemu virtio-1 > > > > I've

On Fri, 24 Oct 2014 00:42:20 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Tue, Oct 07, 2014 at 04:39:56PM +0200, Cornelia Huck wrote: > > This patchset aims to get us some way to implement virtio-1 compliant > > and transitional devices in qemu. Branch available at > > > > git://github.com/cohuck/qemu virtio-1 > > > > I've

On Fri, 26 Apr 2019 20:32:41 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > This patch addresses the most basic stuff (mostly what is required for > virtio-ccw), and does take care of QDIO or any devices. "does not take care of QDIO",

On Fri, 26 Apr 2019 20:32:41 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > This patch addresses the most basic stuff (mostly what is required for > virtio-ccw), and does take care of QDIO or any devices. "does not take care of QDIO",

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Tue, Feb 10, 2015 at 12:02:37PM +1030, Rusty Russell wrote: >> Jason Wang <jasowang at redhat.com> writes: >> > This patch enables the interrupt coalescing setting through ethtool. >> >> The problem is that there's nothing network specific about interrupt >> coalescing. I can see

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Tue, Feb 10, 2015 at 12:02:37PM +1030, Rusty Russell wrote: >> Jason Wang <jasowang at redhat.com> writes: >> > This patch enables the interrupt coalescing setting through ethtool. >> >> The problem is that there's nothing network specific about interrupt >> coalescing. I can see

...y :) So, what is a high-level summary of areas that need the treatment? What I get from looking at the patches so far, it's: - stuff that is written by the hypervisor's interrupt injection code: IRB, indicators, etc. - buffers that are filled by a channel program: sense, sense id, etc. - ccws themselves (because of translation?)

...; > as the irb.ecw is used as channel program data. And that needs to be > shared. Ah, I see. So it's more "guest points to some memory where the hypervisor needs to write data"? > > > - buffers that are filled by a channel program: sense, sense id, etc. > > - ccws themselves (because of translation?) > > > > Right. The idea is: smallish, basically fixed size a readily available > control blocks (specified as a ) are copied back and forth by the As a what? :) > ultravisor (via SIE SD). Ok. It's really hard to be sure from the outs...

...is a simple extension of the config space, it should just work for ccw (the Linux guest driver currently uses 0x100 as max config space size, which I grabbed from pci at the time I wrote it). But looking at this virtio_pci_common_cfg stuff, it seems to contain a lot of things that are handled via ccws on virtio-ccw (like number of queues or device status). Having an extra ccw just for changing this delay value seems like overkill. On the basic topic of interrupt coalescing: With adapter interrupts, virtio-ccw already has some kind of coalescing: The summary indicator is set just once and an int...

...is a simple extension of the config space, it should just work for ccw (the Linux guest driver currently uses 0x100 as max config space size, which I grabbed from pci at the time I wrote it). But looking at this virtio_pci_common_cfg stuff, it seems to contain a lot of things that are handled via ccws on virtio-ccw (like number of queues or device status). Having an extra ccw just for changing this delay value seems like overkill. On the basic topic of interrupt coalescing: With adapter interrupts, virtio-ccw already has some kind of coalescing: The summary indicator is set just once and an int...

...void ccw_timeout_log(struct ccw_device *cdev) sizeof(struct tcw), 0); } else { printk(KERN_WARNING "cio: orb indicates command mode\n"); - if ((void *)(addr_t)orb->cmd.cpa == &private->sense_ccw || - (void *)(addr_t)orb->cmd.cpa == cdev->private->iccws) + if ((void *)(addr_t)orb->cmd.cpa == &private->dma_area->sense_ccw || + (void *)(addr_t)orb->cmd.cpa == cdev->private->dma_area->iccws) printk(KERN_WARNING "cio: last channel program " "(intern):\n"); else @@ -143,18 +143,18 @@...

...void ccw_timeout_log(struct ccw_device *cdev) sizeof(struct tcw), 0); } else { printk(KERN_WARNING "cio: orb indicates command mode\n"); - if ((void *)(addr_t)orb->cmd.cpa == &private->sense_ccw || - (void *)(addr_t)orb->cmd.cpa == cdev->private->iccws) + if ((void *)(addr_t)orb->cmd.cpa == + &private->dma_area->sense_ccw || + (void *)(addr_t)orb->cmd.cpa == + cdev->private->dma_area->iccws) printk(KERN_WARNING "cio: last channel program " "(intern):\n"); else @@ -143,...

...void ccw_timeout_log(struct ccw_device *cdev) sizeof(struct tcw), 0); } else { printk(KERN_WARNING "cio: orb indicates command mode\n"); - if ((void *)(addr_t)orb->cmd.cpa == &private->sense_ccw || - (void *)(addr_t)orb->cmd.cpa == cdev->private->iccws) + if ((void *)(addr_t)orb->cmd.cpa == + &private->dma_area->sense_ccw || + (void *)(addr_t)orb->cmd.cpa == + cdev->private->dma_area->iccws) printk(KERN_WARNING "cio: last channel program " "(intern):\n"); else @@ -143,...

...void ccw_timeout_log(struct ccw_device *cdev) sizeof(struct tcw), 0); } else { printk(KERN_WARNING "cio: orb indicates command mode\n"); - if ((void *)(addr_t)orb->cmd.cpa == &private->sense_ccw || - (void *)(addr_t)orb->cmd.cpa == cdev->private->iccws) + if ((void *)(addr_t)orb->cmd.cpa == + &private->dma_area->sense_ccw || + (void *)(addr_t)orb->cmd.cpa == + cdev->private->dma_area->iccws) printk(KERN_WARNING "cio: last channel program " "(intern):\n"); else @@ -143,...