[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH V1 01/12] hvm/ioreq: Make x86's IOREQ feature common
Hi, On 04/08/2020 20:11, Stefano Stabellini wrote: On Tue, 4 Aug 2020, Julien Grall wrote: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 evenhave 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?On the QEMU side, it looks like PIO (address_space_io) is used in connection with the emulation of the "in" or "out" instructions, see ioport.c:cpu_inb for instance. Some parts of PCI on QEMU emulate PIO space regardless of the architecture, such as hw/pci/pci_bridge.c:pci_bridge_initfn. However, because there is no "in" and "out" on ARM, I don't think address_space_io can be accessed. Specifically, there is no equivalent for target/i386/misc_helper.c:helper_inb on ARM. So how PCI I/O BAR are accessed? Surely, they could be used on Arm, right? Cheers, -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |