WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] A different probklem with save/restore on C/S 14823.

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] A different probklem with save/restore on C/S 14823.
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 13 Apr 2007 18:34:26 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 13 Apr 2007 10:31:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0B018E1BEB@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acd96tTWE6bfmOneEduH7gAWy6hiGQAACQawAABmlkUAADGnsAABKFp7
Thread-topic: [Xen-devel] A different probklem with save/restore on C/S 14823.
User-agent: Microsoft-Entourage/11.3.3.061214
On 13/4/07 18:24, "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:

> However, my guest does A LOT of IOIO exits (it's an IDE test-app), with
> some HLT and IRQ exits thrown in for good measure. So if the guest is
> doing IOIO exit it would end up in platform.c:844 before it gets to
> hvm_do_resume?  Or are you saying that we should crash as soon as the
> guest restarts, because that's done through hvm_do_resume?

Exactly. hvm_do_resume() should always be executed when an HVM VCPU gets
scheduled onto a physical CPU (it's part of the schedule_tail). So it should
execute before your first vmentry, and hence before your first vmexit. And
shared_page_va is sticky: once it's set it stays set. It shouldn't ever get
zapped to zero while a guest is running.

> Would a check for zero in get_vio() with domain_crash_synchronous() be a
> "good thing" here, or is that too time-consuming in a relatively
> time-critical path of HVM?

Could do. But hvm_do_resume() is the one to concentrate on.

 -- Keir

> I will look at it on Monday (before I update to the new version, just to
> make sure I can reproduce it still ;-) ).



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>