On 12/2/19 1:16 AM, Jan Kiszka wrote: > On 27.11.19 18:19, Jan Kiszka wrote: >> Hi Liang, >> >> On 27.11.19 16:28, Liang Yan wrote: >>> >>> >>> On 11/11/19 7:57 AM, Jan Kiszka wrote: >>>> To get the ball rolling after my presentation of the topic at KVM Forum >>>> [1] and many fruitful discussions around it, this is a first concrete >>>> code series. As discussed, I'm starting with the IVSHMEM implementation >>>> of a QEMU device and server. It's RFC because, besides specification >>>> and >>>> implementation details, there will still be some decisions needed about >>>> how to integrate the new version best into the existing code bases. >>>> >>>> If you want to play with this, the basic setup of the shared memory >>>> device is described in patch 1 and 3. UIO driver and also the >>>> virtio-ivshmem prototype can be found at >>>> >>>> >>>> http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/ivshmem2 >>>> >>>> >>>> Accessing the device via UIO is trivial enough. If you want to use it >>>> for virtio, this is additionally to the description in patch 3 >>>> needed on >>>> the virtio console backend side: >>>> >>>> modprobe uio_ivshmem >>>> echo "1af4 1110 1af4 1100 ffc003 ffffff" > >>>> /sys/bus/pci/drivers/uio_ivshmem/new_id >>>> linux/tools/virtio/virtio-ivshmem-console /dev/uio0 >>>> >>>> And for virtio block: >>>> >>>> echo "1af4 1110 1af4 1100 ffc002 ffffff" > >>>> /sys/bus/pci/drivers/uio_ivshmem/new_id >>>> linux/tools/virtio/virtio-ivshmem-console /dev/uio0 >>>> /path/to/disk.img >>>> >>>> After that, you can start the QEMU frontend instance with the >>>> virtio-ivshmem driver installed which can use the new /dev/hvc* or >>>> /dev/vda* as usual. >>>> >>>> Any feedback welcome! >>> >>> Hi, Jan, >>> >>> I have been playing your code for last few weeks, mostly study and test, >>> of course. Really nice work. I have a few questions here: >>> >>> First, qemu part looks good, I tried test between couple VMs, and device >>> could pop up correctly for all of them, but I had some problems when >>> trying load driver. For example, if set up two VMs, vm1 and vm2, start >>> ivshmem server as you suggested. vm1 could load uio_ivshmem and >>> virtio_ivshmem correctly, vm2 could load uio_ivshmem but could not show >>> up "/dev/uio0", virtio_ivshmem could not be loaded at all, these still >>> exist even I switch the load sequence of vm1 and vm2, and sometimes >>> reset "virtio_ivshmem" could crash both vm1 and vm2. Not quite sure this >>> is bug or "Ivshmem Mode" issue, but I went through ivshmem-server code, >>> did not related information. >> >> If we are only talking about one ivshmem link and vm1 is the master, >> there is not role for virtio_ivshmem on it as backend. That is purely >> a frontend driver. Vice versa for vm2: If you want to use its ivshmem >> instance as virtio frontend, uio_ivshmem plays no role. >> Hi, Jan,
Sorry for the late response. Just came back from Thanksgiving holiday. I have a few questions here. First, how to decide master/slave node? I used two VMs here, they did not show same behavior even if I change the boot sequence. Second, in order to run virtio-ivshmem-console demo, VM1 connect to VM2 Console. So, need to install virtio frontend driver in VM2, then install uio frontend driver in VM1 to get "/dev/uio0", then run demo, right? Could you share your procedure? Also, I could not get "/dev/uio0" all the time. >> The "crash" is would be interesting to understand: Do you see kernel >> panics of the guests? Or are they stuck? Or are the QEMU instances >> stuck? Do you know that you can debug the guest kernels via gdb (and >> gdb-scripts of the kernel)? >> They are stuck, no kernel panics, It's like during console connection, I try to load/remove/reset module from the other side, then two VMs are stuck. One VM could still run if I killed the other VM. Like I said above, it may be just wrong operation from my side. I am working on ivshmem-block now, it is easier to understand for dual connection case. >>> >>> I started some code work recently, such as fix code style issues and >>> some work based on above testing, however I know you are also working on >>> RFC V2, beside the protocol between server-client and client-client is >>> not finalized yet either, things may change, so much appreciate if you >>> could squeeze me into your develop schedule and share with me some >>> plans, :-) Maybe I could send some pull request in your github repo? >> >> I'm currently working on a refresh of the Jailhouse queue and the >> kernel patches to incorporate just two smaller changes: >> >> - use Siemens device ID >> - drop "features" register from ivshmem device >> >> I have not yet touched the QEMU code for that so far, thus no conflict >> yet. I would wait for your patches then. >> >> If it helps us to work on this together, I can push things to github >> as well. Will drop you a note when done. We should just present the >> outcome frequently as new series to the list. Yeah, this would be easier this way, I will just send pr in your github and let you handle mailing list in the future. > > I've updated my queues, mostly small changes, mostly to the kernel bits. > Besides the already announced places, you can also find them as PR > targets on > > https://github.com/siemens/qemu/commits/wip/ivshmem2 > https://github.com/siemens/linux/commits/queues/ivshmem2 > Yeah, I saw them, including the linux.git side, just did a rebase today, will send my stuff ASAP. > To give the whole thing broader coverage, I will now also move forward > and integrate the current state into Jailhouse - at the risk of having > to rework the interface there once again. But there are a number of > users already requiring the extended features (or even using them), plus > this gives a nice test coverage of key components and properties. > Yeah, that would be nice to have a summary, looking forward to it. Best, Liang > Jan > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/877b0cd9-d1c5-00c9-c4b6-567c67740962%40suse.com.
