Στις 2021-05-31 21:53, John Hauser έγραψε:
>> John Hauser:
>> > Maybe there's a miscommunication here.  We're talking about memory that
>> > comes with a device, which everyone considers to be part of the device,
>> > and which is mapped into the machines's address space as "I/O".  We're
>> > not talking about a device doing DMA to/from regular main memory.
>
> Greg Favor:
>> Thanks.  Then the PMA I/O attribute will apply to all accesses to the
>> device and there is no need for a "virtual I/O" bit.  (Just like in
>> x86 and
>> ARM, Svpbmt will not change this fact.  Similarly, if for example
>> VS-stage
>> says I/O type, then G-stage can't override that.)
>
> When a device is being entirely emulated by a hypervisor, where do you
> assume these "PMA I/O attributes" for the device come from, obviating
> any need for a "virtual I/O" bit in G-stage address translation?
>
>> > The scenario is a hypervisor emulating a device of the type above,
>> > where the device has its own memory in the address space that is
>> > supposed to be considered I/O.  However, for efficiency, the hypervisor
>> > doesn't want to trap every access to this emulated device memory, so it
>> > substitutes main memory for emulation purposes.
>>
>> As I've noted, this isn't possible in x86 or ARM (or what will be the
>> latest Svpbmt).
>
> I'm shocked to hear that emulating a traditional network interface card
> (NIC) on an x86 machine requires trapping every individual access to
> one of the NIC's buffers.  Have x86's really been this crippled all
> along, and I wasn't aware?
>

With virtio we have virtqueues (ring buffers) for communicating with the
host, so we don't trap on every access, here is an interesting overview:
https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-and-phone

Regards,
Nick