On Fri, 1 Mar 2019 14:18:21 +0100 (CET) Sebastian Ott <sebott@xxxxxxxxxxxxx> wrote: > On Fri, 1 Mar 2019, Cornelia Huck wrote: > > On Fri, 1 Mar 2019 13:14:38 +0100 (CET) > > Sebastian Ott <sebott@xxxxxxxxxxxxx> wrote: > > > The iomap, readb stuff is only usable in a PCI context on s390. But what > > > is the problem here? virtio_ccw knows it's not a PCI driver - it doesn't > > > have to use this stuff.. > > > > The device has to put the shared regions somewhere. If the virtio-pci > > transport is used, it's just a normal area within a BAR (IIUC), and > > should be handled just like normal pci memory. > > > > The problem is where to put it if the virtio-ccw transport is used. The > > idea was to put it in its own region (a device-memory region) and allow > > the guest some way to discover that region (which is not within the > > normal system memory from the guest's POW, just as pci memory isn't). > > However, if we do that, we end up having the shared regions in > > different regions depending upon whether the pci or the ccw transport > > is used. Having pci use the special device memory on s390x does not > > really sound like a good idea, either. Nor does putting it into pci > > memory and accessing it from the ccw transport... > > How should virtio_ccw access this memory? Only via CCW programs? In this > case you don't have to put it in the guests address space. Or should > standard memory instructions (lg,st) be used? In this case maybe the > 1-to-1 mapping or the vmalloc space?? The idea was to use standard memory instructions (i.e. both host and guest can read from/write to the region at any time). There was also the idea to read/write this from the guest side only via ccws, for which we wouldn't need a new address space, but that would have serious drawbacks like not being able to read/write from an atomic context.
