[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 01/11] xen/manage: keep track of the on-going suspend mode
- To: Anchal Agarwal <anchalag@xxxxxxxxxx>
- From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Date: Thu, 3 Jun 2021 16:11:46 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EzbIaADvFD7uc8vEJGwdT6z9IDFMtlnY18zZuVGI6Co=; b=J5XjqSu2YitBrbNbjHGzYnJWEqc21v+s7dX9xNR5aI6D9lGqMbggfvtwyDiPDuSiNx04gr6vFydZh8DGIPWjdJtTkICHkVF1RO2dpmJ7x7cROou1J24Ldod9XT9+SWNOEwWR/8Qyxstduw+Mgz0W1HpvMP3TvW8OEj+MN9keIjxCvftuZ8u1Z8EwKt24mKHdkxy0U8XkqkPkQhrLxTNoPEtix2Iy1+LCYFL+xz1/QNRg0nfeVc66nwWkpqsUkLbD5Lbv/yk+dID8CdGQRvNQWPEH4vx6Y4D4NwDEZjX6f56ZcglWiNWKWXymhmtScWXP8pCEre/m2mujgwczX/xTDQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAQEjZccADZazKafFH+jRFLq5CT8qSQ3g1zo9pl4QhxU53CuPRzO+QqYGHsFcL5BlAtB8y3IHotJA/NIOUIlKSpi2XgJuOYbdHnfe05qhegBkPDQU+xPF33wKjZDbICGWWk8p52M/oZt4N2TE5oUL/OGGaXJzlASXm02FMnyUjWd4seITNWiSAeLLfebu/fyg6A/dmyV/O6KaHllbHUEWj4duW/aBTQRJMoWv4naZfNLFp4owHNrmWLLuvyJk4W93/f2LC9TF6fTVERQzSY8NPFTb1oHNSOKUsaJWtnNQY3h83B5QTq9CDuCaAyenvMNrHF9UGZrupPLczTq3Lw9cA==
- Authentication-results: amazon.co.uk; dkim=none (message not signed) header.d=none;amazon.co.uk; dmarc=none action=none header.from=oracle.com;
- Cc: "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "bp@xxxxxxxxx" <bp@xxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "jgross@xxxxxxxx" <jgross@xxxxxxxx>, "linux-pm@xxxxxxxxxxxxxxx" <linux-pm@xxxxxxxxxxxxxxx>, "linux-mm@xxxxxxxxx" <linux-mm@xxxxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, "konrad.wilk@xxxxxxxxxx" <konrad.wilk@xxxxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, "axboe@xxxxxxxxx" <axboe@xxxxxxxxx>, "davem@xxxxxxxxxxxxx" <davem@xxxxxxxxxxxxx>, "rjw@xxxxxxxxxxxxx" <rjw@xxxxxxxxxxxxx>, "len.brown@xxxxxxxxx" <len.brown@xxxxxxxxx>, "pavel@xxxxxx" <pavel@xxxxxx>, "peterz@xxxxxxxxxxxxx" <peterz@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "vkuznets@xxxxxxxxxx" <vkuznets@xxxxxxxxxx>, "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "dwmw@xxxxxxxxxxxx" <dwmw@xxxxxxxxxxxx>
- Delivery-date: Thu, 03 Jun 2021 20:12:55 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 6/2/21 3:37 PM, Anchal Agarwal wrote:
> On Tue, Jun 01, 2021 at 10:18:36AM -0400, Boris Ostrovsky wrote:
>>
> The resume won't fail because in the image the xen_vcpu and xen_vcpu_info are
> same. These are the same values that got in there during saving of the
> hibernation image. So whatever xen_vcpu got as a value during boot time
> registration on resume is
> essentially lost once the jump into the saved kernel image happens.
> Interesting
> part is if KASLR is not enabled boot time vcpup mfn is same as in the image.
Do you start the your guest right after you've hibernated it? What happens if
you create (and keep running) a few other guests in-between? mfn would likely
be different then I'd think.
> Once you enable KASLR this value changes sometimes and whenever that happens
> resume gets stuck. Does that make sense?
>
> No it does not resume successfully if hypercall fails because I was trying to
> explicitly reset vcpu and invoke hypercall.
> I am just wondering why does restore logic fails to work here or probably I am
> missing a critical piece here.
If you are not using KASLR then xen_vcpu_info is at the same address every time
you boot. So whatever you registered before hibernating stays the same when you
boot second time and register again, and so successful comparison in
xen_vcpu_setup() works. (Mostly by chance.)
But if KASLR is on then this comparison not failing should cause xen_vcpu
pointer in the loaded image to become bogus because xen_vcpu is now registered
for a different xen_vcpu_info address during boot.
>>> Another line of thought is something what kexec does to come around this
>>> problem
>>> is to abuse soft_reset and issue it during syscore_resume or may be before
>>> the image get loaded.
>>> I haven't experimented with that yet as I am assuming there has to be a way
>>> to re-register vcpus during resume.
>>
>> Right, that sounds like it should work.
>>
> You mean soft reset or re-register vcpu?
Doing something along the lines of a soft reset. It should allow you to
re-register. Not sure how you can use it without Xen changes though.
-boris
|