| Message ID | 53d783d7-aa53-f2de-6aa3-bd266f176dfb@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: insn-fetch related emulation adjustments | expand |
On 03/12/2021 11:21, Jan Beulich wrote: > The SDM explicitly permits this, and since that's sensible behavior > don't special case AMD (where the PM doesn't explicitly say so). APM explicitly says so too. "The CLFLUSH instruction executes at any privilege level. CLFLUSH performs all the segmentation and paging checks that a 1-byte read would perform, except that it also allows references to execute-only segments." and "The CLFLUSHOPT instruction executes at any privilege level. CLFLUSHOPT performs all the segmentation and paging checks that a 1-byte read would perform, except that it also allows references to execute-only segments." > Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook") > Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> > Signed-off-by: Jan Beulich <jbeulich@suse.com> With the commit message tweaked, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>. Far less invasive than I was fearing. ~Andrew
On 03.12.2021 12:48, Andrew Cooper wrote: > On 03/12/2021 11:21, Jan Beulich wrote: >> The SDM explicitly permits this, and since that's sensible behavior >> don't special case AMD (where the PM doesn't explicitly say so). > > APM explicitly says so too. > > "The CLFLUSH instruction executes at any privilege level. CLFLUSH > performs all the segmentation and paging checks that a 1-byte read would > perform, except that it also allows references to execute-only segments." > > and > > "The CLFLUSHOPT instruction executes at any privilege level. CLFLUSHOPT > performs all the segmentation and paging checks that a 1-byte read would > perform, except that it also allows references to execute-only segments." Somehow I didn't read further after the page table related paragraph, perhaps on the assumption that like in the SDM it would be all in one paragraph. >> Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook") >> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > With the commit message tweaked, Reviewed-by: Andrew Cooper > <andrew.cooper3@citrix.com>. Far less invasive than I was fearing. Thanks. I've switched to simply saying "Both SDM and PM explicitly permit this." Jan
On 03/12/2021 03:21, Jan Beulich wrote: > The SDM explicitly permits this, and since that's sensible behavior > don't special case AMD (where the PM doesn't explicitly say so). > > Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook") > Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Paul Durrant <paul@xen.org>
--- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -2310,7 +2310,9 @@ static int hvmemul_cache_op( ASSERT(!is_x86_system_segment(seg)); rc = hvmemul_virtual_to_linear(seg, offset, 0, NULL, - hvm_access_read, hvmemul_ctxt, &addr); + op != x86emul_clwb ? hvm_access_none + : hvm_access_read, + hvmemul_ctxt, &addr); if ( rc != X86EMUL_OKAY ) break;
The SDM explicitly permits this, and since that's sensible behavior don't special case AMD (where the PM doesn't explicitly say so). Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com>