On 14.09.20 17:59, Jan Beulich wrote:
Hi Jan
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -35,6 +35,13 @@ static inline struct hvm_ioreq_server
*get_ioreq_server(const struct domain *d,
return GET_IOREQ_SERVER(d, id);
}
+static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
+{
+ return ioreq->state == STATE_IOREQ_READY &&
+ !ioreq->data_is_ptr &&
+ (ioreq->type != IOREQ_TYPE_PIO || ioreq->dir != IOREQ_WRITE);
+}
While the PIO aspect has been discussed to some length, what about
the data_is_ptr concept? I didn't think there were Arm insns fitting
this? Instead I thought some other Arm-specific adjustments to the
protocol might be needed. At which point the question of course would
be in how far ioreq_t as a whole really fits Arm in its current shape.
I may mistake here but I don't think the "data_is_ptr" is supported.
It worth mentioning that on Arm, all the accesses to MMIO region will do
a single memory access.
So we set "df" to 0 and "count" to 1. Other ioreq_t fields are in use.
--
Regards,
Oleksandr Tyshchenko
