On Fri, 1 Mar 2019 13:14:38 +0100 (CET) Sebastian Ott <sebott@xxxxxxxxxxxxx> wrote: > On Thu, 21 Feb 2019, Halil Pasic wrote: > > On Thu, 21 Feb 2019 15:46:08 +0000 > > "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx> wrote: > > > * Cornelia Huck (cohuck@xxxxxxxxxx) wrote: > > > > This is getting a bit confusing... let me try to summarize: > > > > > > > > - We introduce a special area where shared memory areas are supposed to > > > > live. > > > > - If a virtio device accessed via ccw defines shared regions, the > > > > driver can discover them via a new ccw that indicates an address in > > > > that special area. > > > > > > Right. > > > > > > > - If a virtio device accessed via pci defines shared regions, the > > > > driver will want to discover them via the same mechanism as on other > > > > platforms. If I read > > > > https://lists.oasis-open.org/archives/virtio-comment/201901/msg00003.html > > > > correctly, this will mean an offset into a BAR. This will be a normal > > > > pci memory region. > > > > > > Right; note that like any other BAR it's upto the guest to write the BAR > > > to select which area of GPA it wants the BAR to map to. > > > > > > > Now, this sounds to me that we'll have regions in different memory > > > > regions, depending on whether they are accessed via ccw or via pci. Not > > > > sure if that's a problem. > > > > > > As long as they stay out of each others way it shouldn't be. > > > > > > > I'm not sure. What I'm concerted about is: > > * if it is a virtio-ccw device it would need to access the shared memory via > > normal memory access instructions. > > * if it is a virtio-pci device it would need to access the shared memory as > > pci memory, that is via special PCI memory access instructions. > > I spent all morning going through this thread trying to understand what > you want to do here. Frankly, I fail to understand what's even new here. I hope it was not too bad; this thread is long and twisty. > > We have emulated devices which are recognized by the guest OS' standard > bus code (PCI, CCW) but have a special ID such that a virtio driver is > bound to them. This driver uses standard accessors (pci_iomap, readb; > ccw_device_start) which have to be trapped by QEMU/KVM. What do you want > to change in this setup? Aren't the resources the virtio drivers access > shared memory today? It is not what virtio uses today. For example, the virtio driver will discover the device's virtqueues, allocate memory for it, and let the device know where that memory is. The important point is that this is _guest_ memory, i.e. withing the memory region that the host has assigned to the guest for its use as system memory. For the new shared regions, we want to use _host_ memory. Again, the driver will discover which shared regions the device has... but it won't allocate anything in guest memory, it will simply start to use those shared regions. In this case, we don't want to use the guest's system memory, as it will already have used it for its own purposes. The idea was to put shared regions into a different memory region. > 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...
