Comments

While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM,
but write to I/O handler", there is no flag indicating that an I/O
region which is fully managed by I/O handlers can still be hosting
executable code. One use case for this are flash device models that
switch to I/O mode during reprogramming. Not all reprogramming states
modify to read data, thus practically allow to continue execution.
Moreover, we need to avoid switching the modes too frequently for
performance reasons which requires fetching opcodes while still in I/O
device mode.
So this patch introduces the IO_MEM_EXEC flag. Flash devices need to set
it independent of their access mode. The flag is propagated from
PhysPageDesc into the TLB, and get_page_addr_code is evaluating it
instead of IO_MEM_ROMD. Testing for the latter was so far a nop anyway
as this flag never made it into the TLB.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
---
cpu-common.h | 2 ++
exec-all.h | 2 +-
exec.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)

Jan Kiszka wrote:
> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM,> but write to I/O handler", there is no flag indicating that an I/O> region which is fully managed by I/O handlers can still be hosting> executable code. One use case for this are flash device models that> switch to I/O mode during reprogramming. Not all reprogramming states> modify to read data, thus practically allow to continue execution.> Moreover, we need to avoid switching the modes too frequently for> performance reasons which requires fetching opcodes while still in I/O> device mode.
I like this change.
Does "fetching opcodes while still in I/O device mode" fetch opcodes
from the RAM backing, or via the I/O read handlers?
If the latter, I'm wondering how KVM would cope with that.
Thanks,
-- Jamie

Jamie Lokier wrote:
> Jan Kiszka wrote:>> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM,>> but write to I/O handler", there is no flag indicating that an I/O>> region which is fully managed by I/O handlers can still be hosting>> executable code. One use case for this are flash device models that>> switch to I/O mode during reprogramming. Not all reprogramming states>> modify to read data, thus practically allow to continue execution.>> Moreover, we need to avoid switching the modes too frequently for>> performance reasons which requires fetching opcodes while still in I/O>> device mode.> > I like this change.> > Does "fetching opcodes while still in I/O device mode" fetch opcodes> from the RAM backing, or via the I/O read handlers?
Via the latter. This is most "correct" in that broken guests that jump
to the ROM while it's in some critical write cycle will properly crash.
> > If the latter, I'm wondering how KVM would cope with that.
I think it won't work without extending KVM to fetch - as a last resort
- also from I/O devices. Or we give up the "correctness" and keep the
RAM-base KVM slot for IO_MEM_EXEC regions. That should be solvable in a
transparent way in kvm_set_phys_mem.
Jan

Jan Kiszka wrote:
> Jamie Lokier wrote:>> Jan Kiszka wrote:>>> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM,>>> but write to I/O handler", there is no flag indicating that an I/O>>> region which is fully managed by I/O handlers can still be hosting>>> executable code. One use case for this are flash device models that>>> switch to I/O mode during reprogramming. Not all reprogramming states>>> modify to read data, thus practically allow to continue execution.>>> Moreover, we need to avoid switching the modes too frequently for>>> performance reasons which requires fetching opcodes while still in I/O>>> device mode.>> I like this change.>>>> Does "fetching opcodes while still in I/O device mode" fetch opcodes>> from the RAM backing, or via the I/O read handlers?> > Via the latter. This is most "correct" in that broken guests that jump> to the ROM while it's in some critical write cycle will properly crash.> >> If the latter, I'm wondering how KVM would cope with that.> > I think it won't work without extending KVM to fetch - as a last resort> - also from I/O devices. Or we give up the "correctness" and keep the> RAM-base KVM slot for IO_MEM_EXEC regions. That should be solvable in a> transparent way in kvm_set_phys_mem.
Which, of course, would break CFI reads etc. for KVM guest. So this
feature actually requires additional support by KVM to fetch code from
I/O devices.
Jan