Re: [PATCH RFC V2 1/6] xen: Emulate with no writes

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 07/11/2014 07:23 PM, Andrew Cooper wrote:
> On 11/07/14 16:43, Razvan Cojocaru wrote:
>> +void hvm_emulate_one_full(bool_t nowrite,
>> +    unsigned int unhandleable_trapnr,
>> +    int unhandleable_errcode)
>> +{
>> +    struct hvm_emulate_ctxt ctx[1] = {};
> 
> This construct looks suspect.  What is wrong with
> 
> struct hvm_emulate_ctxt ctx = { 0 }; and using &ctx below ?

Nothing, will replace it.

>> +    int rc = X86EMUL_RETRY;
>> +
>> +    hvm_emulate_prepare(ctx, guest_cpu_user_regs());
>> +
>> +    while ( rc == X86EMUL_RETRY )
>> +    {
>> +        if ( nowrite )
>> +            rc = hvm_emulate_one_no_write(ctx);
>> +        else
>> +            rc = hvm_emulate_one(ctx);
>> +    }
> 
> This however is not appropriate.  X86EMUL_RETRY can include "talk to
> dom0 and get the paging subsystem to page in part of the VM", which
> given some current work-in-progress can be to the other end of a network
> connection on the far side of an optimistic migration.
> 
> You can't cause a Xen pcpu to spin like this for that length of time. 
> Anything longer than a second and all other pcpus will block against the
> time calibration rendezvous, and longer than 5 will panic on the NMI
> watchdog.

I see. Would you be able to recommend a safer way of handling
X86EMUL_RETRY here? Basically what I'm trying to achieve is simply
making sure that the instruction either ran or was impossible to run
when hvm_emulate_one_full() returns.

I guess I should run hvm_emulate_one() / hvm_emulate_one_no_write() once
and just return on X86EMUL_RETRY?


Thanks,
Razvan Cojocaru