On 02/10/2019 08:07, Jan Beulich wrote: > On 01.10.2019 21:44, Andrew Cooper wrote: >> In this example, hardware can the emulator can disagree by using a >> different access width. >> >> I've been experimenting with my Rome system, and an emulator hardcoded >> to use 2-byte accesses. After some investigation, the livelock only >> occurs for access-rights faults. Translation faults get identified as >> not a shadow fault, and bounced back to the guest. >> >> Shadow guests can use PKRU, so can generate an access fault by marking >> the page at 0x2000 as no-access, so I think that in principle, this >> change will result in a new latent livelock case, but I can't actually >> confirm it. > I think I see what you mean, but then I don't see how this is an > argument against the patch in its current shape: It actually > reduces the cases of disagreement between hardware and emulator.
At the moment, the emulator is strictly 4 bytes, and hardware may be 4 or 2. Therefore, there is no chance of the pipeline yielding #PF while the emulator yielding OK. With the change in place, older Intel parts which do use a 4 byte access now come with a risk of livelock. Whichever parts these are, they predate PKRU so in this specific case, the problem is only theoretical AFAICT. Also, in this specific case, Intel's warning of "Don't use this instruction without a REX prefix" means that we shouldn't see it in anything but test scenarios. > One possibility to make a further step in that direction would > be to make behavior dependent upon the underlying hardware's > vendor, rather than the one the guest sees. I considered this. It would work on native (at the expense of complicating the emulator), but won't work properly if Xen is virtualisied and migrated. I can't see a way around this. Furthermore, we can't execute the instruction against a mapping of the guest, because the problem here is determining the width of the access, which is information needed to construct the mapping in the first place. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
