From mboxrd@z Thu Jan  1 00:00:00 1970
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH RFC V2 1/6] xen: Emulate with no writes
Date: Fri, 11 Jul 2014 21:00:18 +0300
Message-ID: <53C02632.4090606@bitdefender.com>
References: <1405093418-23481-1-git-send-email-rcojocaru@bitdefender.com>
	<53C00F94.5020907@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <53C00F94.5020907@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Cc: mdontu@bitdefender.com, tim@xen.org, JBeulich@suse.com
List-Id: xen-devel@lists.xenproject.org

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