[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 21:49:04 -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=NbRCNCPY8R1hSw7JhonvH/YFtcFYtqbJUiX8S0oc01Y=; b=R29twU9k55JT/x8Dai0HMzG2ytvxffZuwKySk9aB1ds98kMRisHGfylf/f8m0e5j7CL4unowS997sZs99QACFETXE88r9oP6Oiom62JAafLZ2a+PfR15rf5a5kDo64/okht5qy2wfAs2VNJkxIbLtvWsr5MnNXlUn3lRJ52y2pAKwujdAnaFG+pgEEb7//J5qf8B96qjKCA1XhXz5ZTmbUyXeKO2rclj6IJdimhY4hevaukPlX+jXHDETIJIUt/b1cgdfj7YrrwHFxlyuay0cwtoOkSrYB6s8O53fuLRoBcXXQRu1VyP+/ao0xzYan9Cpc8vXTRaEx/OWHrBC10xRQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y9FY/OcteczFF+sqeu3i3cWk84bjrEe2Nyzg9yjw+p5WAjW8czPz9Y35uBgsCZRNqgiCE5CHFfQ0nq0dqS8wndNlPt8nuC2w+e+mBFY3QeYh/kpvuPgjWjHgN2mDtwu4iXc2Za9kPIjM5sC96lwSahvW+XKAch95SiQs6tTYj+D/EcmlfgmsRB2eJjH888UpuBeMrtEX7xlbsrW/DOd3Zhqvq1MCt4pTDLS8G+ivv86S1PZergHeDT174usqlt8z0O44HV5b972IDZTDdhQaKH8h5XkoEQRXtRaVxpMYI3teixlGBJKoFOQYAvB1aBWwgY0+dMh2DPwRWGGervOYrg==
- 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: Fri, 04 Jun 2021 01:50:14 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 6/3/21 7:27 PM, Anchal Agarwal wrote:
> On Thu, Jun 03, 2021 at 04:11:46PM -0400, Boris Ostrovsky wrote:
>
>> 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.
>>
> The reason for that I think is once you jump into the image that information
> is
> getting lost. But there is some residue somewhere that's causing the resume
> to
> fail. I haven't been able to pinpoint the exact field value that may be
> causing
> that issue.
xen_vcpu now points to address which is not where the hypervisor thinks
vcpu_info should be.
> Correct me if I am wrong here, but even if hypothetically I put a hack to
> tell the kernel
> somehow re-register vcpu it won't pass because there is no hypercall to
> unregister it in first place?
Right. You will be shown the door in map_vcpu_info():
if ( !mfn_eq(v->vcpu_info_mfn, INVALID_MFN) )
return -EINVAL;
> Can the resumed kernel use the new values in that
> case [Now this is me just throwing wild guesses!!]
I don't think so --- hypervisor is now pointing to a random location in your
image.
-boris
|
