This document discusses differences in how physical memory mapping is handled between QEMU/KVM and QEMU/Xen implementations. When requesting more than two guest physical pages, QEMU/KVM maps the pages sequentially in host virtual memory, working properly for virtio-ring. However, in QEMU/Xen the mapping can be fragmented and partial, causing issues for virtio-blk. This problem was discovered while tracing virtio-blk crash issues. A fix is being worked on to refactor the physical memory mapping function in QEMU to resolve the issue.

1. 

6. •
•
•
o

7. •
o
•
o
•
o
•
o

9. •
•
o
•
o
o
•
o
virtio: Linux I/O
http://www.ibm.com/developerworks/jp/linux/library/l-virtio/

10. •
•
o
o
IRQ
MSI(-X)
Xen
-
eventchannel
KVM
-

11. •
•
•
•
•
•

12. •
•
•

14. •
o
•
o
o
o
o

15. •
•
•
•

16. •
•
•
•

17. While tracing virtio-blk crash issues, I have found
cpu_physical_memory_map() in upstream-qemu+xen behaves
different with others. This prevents proper work of virtio-ring bundled
in qemu.
When a caller requests more than 2 guest-physical pages, the function
will map the pages in host-virtual, as possible. In kvm+qemu, the
region residents always sequential in host-virtual, so it will work
perfectly. However, in xen+qemu, the region mapping is sometimes
fragmented and partial. ( )

18. Citrix
This is a very serious issue, thank you very much for
spotting it!
I am going to refactor cpu_physical_memory_map to fix the
problem, I‘ll send you a patch as soon as I have it ready.
•
•

19. o
o
o
o
o
o

20. •
•
o
•
o
o
•
o

21. •
•
•
•
•
–
–
–
–