Re: [RFC PATCH V1 01/12] hvm/ioreq: Make x86's IOREQ feature common

[Julien Grall <julien@xxxxxxx>]

Hi,

On 04/08/2020 12:10, Oleksandr wrote:
> On 04.08.20 10:45, Paul Durrant wrote:
> > > +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);
> > > +}
> > I don't think having this in common code is correct. The short-cut of 
> > not completing PIO reads seems somewhat x86 specific. 
Hmmm, looking at the code, I think it doesn't wait for PIO writes to 
complete (not read). Did I miss anything?
> Does ARM even 
> > have the concept of PIO?
> I am not 100% sure here, but it seems that doesn't have.
Technically, the PIOs exist on Arm, however they are accessed the same 
way as MMIO and will have a dedicated area defined by the HW.
AFAICT, on Arm64, they are only used for PCI IO Bar.

Now the question is whether we want to expose them to the Device 
Emulator as PIO or MMIO access. From a generic PoV, a DM shouldn't have 
to care about the architecture used. It should just be able to request a 
given IOport region.
So it may make sense to differentiate them in the common ioreq code as well.

I had a quick look at QEMU and wasn't able to tell if PIOs and MMIOs 
address space are different on Arm as well. Paul, Stefano, do you know 
what they are doing?
Cheers,

--
Julien Grall