On 14.09.20 18:16, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -23,6 +23,40 @@
#include <asm/hvm/ioreq.h>
+struct hvm_ioreq_page {
+ gfn_t gfn;
+ struct page_info *page;
+ void *va;
+};
+
+struct hvm_ioreq_vcpu {
+ struct list_head list_entry;
+ struct vcpu *vcpu;
+ evtchn_port_t ioreq_evtchn;
+ bool pending;
+};
+
+#define NR_IO_RANGE_TYPES (XEN_DMOP_IO_RANGE_PCI + 1)
+#define MAX_NR_IO_RANGES 256
+
+struct hvm_ioreq_server {
+ struct domain *target, *emulator;
+
+ /* Lock to serialize toolstack modifications */
+ spinlock_t lock;
+
+ struct hvm_ioreq_page ioreq;
+ struct list_head ioreq_vcpu_list;
+ struct hvm_ioreq_page bufioreq;
+
+ /* Lock to serialize access to buffered ioreq ring */
+ spinlock_t bufioreq_lock;
+ evtchn_port_t bufioreq_evtchn;
+ struct rangeset *range[NR_IO_RANGE_TYPES];
+ bool enabled;
+ uint8_t bufioreq_handling;
+};
Besides there again being the question of hvm_ prefixes here,
is the bufioreq concept something Arm is meaning to make use
of? If not, this may want to become conditional ...
The hvm_ prefixes will be removed.
Regarding bufioreq concept I agree with what Julien said. Although we
don't need it right away on Arm we can use it later on for the virtio
improvements.
--
Regards,
Oleksandr Tyshchenko
