>>> On 07.12.16 at 14:36, wrote:
> On 07/12/16 08:32, Jan Beulich wrote:
>> And I don't see why the ->cpuid() hook would be required all of the
>> sudden - all its uses are guarded by a NULL check.
>
> You made it convincing argument in c/s 043ad80 "x86: always supply
> .cpuid() handler to x86_em
On 07/12/16 08:32, Jan Beulich wrote:
On 06.12.16 at 18:34, wrote:
>> On 06/12/16 11:15, Jan Beulich wrote:
>>> While the read and fetch hooks are basically unavoidable, write and
>>> cmpxchg aren't really needed by that many insns.
>>>
>>> Signed-off-by: Jan Beulich
>> As a corollary, pleas
>>> On 06.12.16 at 18:34, wrote:
> On 06/12/16 11:15, Jan Beulich wrote:
>> While the read and fetch hooks are basically unavoidable, write and
>> cmpxchg aren't really needed by that many insns.
>>
>> Signed-off-by: Jan Beulich
>
> As a corollary, please can we gain
>
> ASSERT(ops->read && ops
On 06/12/16 11:15, Jan Beulich wrote:
> While the read and fetch hooks are basically unavoidable, write and
> cmpxchg aren't really needed by that many insns.
>
> Signed-off-by: Jan Beulich
As a corollary, please can we gain
ASSERT(ops->read && ops->fetch && ops->cpuid)
at the start of x86_emul
While the read and fetch hooks are basically unavoidable, write and
cmpxchg aren't really needed by that many insns.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1492,6 +1492,8 @@ protmode_load_seg(
{
uint3
