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
signature.asc
Description: OpenPGP digital signature
