[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v8 04/12] x86emul: support SERIALIZE
On 08/05/2020 14:59, Jan Beulich wrote: > On 08.05.2020 15:00, Andrew Cooper wrote: >> On 08/05/2020 08:34, Jan Beulich wrote: >>>>> @@ -5660,6 +5661,18 @@ x86_emulate( >>>>> goto done; >>>>> break; >>>>> >>>>> + case 0xe8: >>>>> + switch ( vex.pfx ) >>>>> + { >>>>> + case vex_none: /* serialize */ >>>>> + host_and_vcpu_must_have(serialize); >>>>> + asm volatile ( ".byte 0x0f, 0x01, 0xe8" ); >>>> There is very little need for an actual implementation here. The VMExit >>>> to get here is good enough. >>>> >>>> The only question is whether pre-unrestricted_guest Intel boxes are >>>> liable to find this in real mode code. >>> Apart from this we also shouldn't assume HVM in the core emulator, >>> I think. >> It's not assuming HVM. Its just that there is no way we can end up >> emulating this instruction from PV context. >> >> If we could end up here in PV context, the exception causing us to >> emulate to begin with would be good enough as well. > With the current way of where/how emulation gets involved - > yes. I'd like to remind you though of the 4-insn window > shadow code tries to emulate over for PAE guests. There > is no intervening #VMEXIT there. > > So do you want me to drop the asm() then, and switch from > host_and_vcpu_must_have(serialize) to just > vcpu_must_have(serialize)? No - keep it as is. This isn't a fastpath, and it is much safer to assume there might be something we've forgotten. (Or perhaps some new future behaviour included in the definition of architecturally serialising). ~Andrew
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |