[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/3] x86/PV: replace assertions in '0' debug key stack dumping


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 18 Oct 2021 17:41:52 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TY/D0QMVjGS3U/WUIUrBzOE/lhuGLCxFMHpuPHZlzIw=; b=YghZxlXQgzmxdshfeC3cCKgJBX9op12tRdQEReGt3poofEdV8OVOHox2LpQPhARB5JHLeQGTXWCeEjFkId7M+lg63PvrKOMvaWSQ4cGSeVrF5V8Qi32E1DSl96M5BoB3XhxyqYQahUFUnSmOAg2CYXDqEnfPDVS9ECv+stGgifsGnBzlLTZCxLukvkognDzDq1Y4wCgVpp5jWjf7wTdaC5CmoSbuXtlpDEJZW9DLDBgx381MNLyeCccPziFL55RHqKqNHENvs4XercEd+ti9CUZG7oLpltK9Zpvj4C105WBNaD8XEvMXBzs7+6FhGYkyGt2d6PZiTcBNgGb7RSaAPA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iW/uT6dmkwzQDh6hjUhqfiig3JhtGY5wtF0NpnKCZP28jxnaYC5UePQIlGSlTuXBTPQ2ptrTO7aM0FMLiU/VCUg4G95SrlpkJdCixeApDVBkf5RSbAX9VKNnvXkl1jiq2PaDsizP7Z+QyXihbmwkOHhRHjNG1QtY83Ns4c4SB7ea+UQ3SLP54i34ePwz5PKS1sdqZMq1YbESM5ef7oZRIG57bCHi7GiY2slkaR/LwpUgqRSRcQSsu6sbVZDPCtpRqp4f9bVwvOabRPrsZavVPpoTcm6LeXwRcZ7Egu2rO8swkj4xG+rEZgwptCAdbF5JRYi4pqiwSfkwEceAI9o0nw==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 18 Oct 2021 15:42:08 +0000
  • Ironport-data: A9a23:vtlYPK9i9Qu8dkPbdwnZDrUDW3mTJUtcMsCJ2f8bNWPcYEJGY0x3x zEYUDqBMvuDMWWkedglPojk9kJXsZTcx4BqQAJr/i88E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si9AttENlFEkvU2ybuOU5NXsZ2YhGGeIdA970Ug6wrZg0tYy6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPh61 9FpmN+pdz4pO6j2yc5MTDcJCHhHaPguFL/veRBTsOSWxkzCNXDt3+9vHAc9OohwFuRfWD8Us 6ZCcXZUM07F17neLLGTE4GAguw5K8bmJsUHs2xIxjDFF/c2B5vERs0m4PcFgWtg35sQRp4yY eJCVzxKaSzbZidwFXwoIsNgne6BokbgJmgwRFW9+vNsvjm7IBZK+KfpGMrYfJqNX8o9tlaVo CfK8nr0BjkeNceD0nyV/3S0nOjNkCjnHoUIG9WQ9PRnnVmSzWw7EwANWB2wpvzRt6Klc4sBc QpOoHNo9PVsshzwJjXgY/GmiHWbujoxGMNuKu0/7Tvc4PvLzVeCX1FRG1atd+canMMxQDUr0 HqAkNXoGSFjvdWpdJ6NyluHhWjtYXZNfAfucQdBFFFfu4Cy/+nfmzqWFo47eJNZmOEZDt0ZL 9qilyM5m6kIxfAC06G27DgraBr9+8CXEGbZCujRN19JDz+Vhqb4P+RECnCBtJ6sybp1qHHb7 RDofODFtIgz4WmlznDlfQn0NOjBCwy5GDPdm0VzOJIq6i6g/XWuFagJvmoieBY0Y5xYJWW4C KM2he+3zMUCVJdNRfQvC79d9uxwlfSwfTgbfqG8giVyjmhZK1bcoXAGib+41GHxikk8+ZzTy r/AGftA+U0yUPw9pBLvHr91+eZymkgWmDOCLbimnk/P+efPOxaopUItbQLmghYRt/jf/m04M r93aqO39vmoeLaiO3aKrdNKcAliwLpSLcmelvG7v9Wre2JOMGogF+XQ0fUmfYlklL5SjeDG4 je2XUow9bY1rSevxdyiZi8xZbXxc4x4qH5nbyUgMUzxgyooYJq17bdZfJwyJOF1+OtmxP9yb v8EZ8TfXagfFmWZo2wQPcvnsYhvVBW3ngbSbSCrVycyIsx7TAvT9966Iga2rHsSDjC6vNcVq qG70l+JWoIKQglvVZ6EaP+mw16rk2IaneZ+AxnBLtVJIR2++4l2MS3hyPQwJphUexnEwzKb0 SeQAAsZ+raR89NkroGRiPnd/YmzEuZ4Ek5LJEXh7O67ZXvA426u4Y5cS+LULzrTY3z5pfe5b uJPwvCibPBexARWs5BxGqpAxL4l44e9vKdTywlpESmZb1mvDb88cHCK0dMW6/9Iz75d/wC3R liO6p9RPrDQYJHpF1sYJQwEaOWf1K5LxmmOvKpteEiqtjVq+LenUFlJO0jegSNQG7J5LYc5z Lpzo8UR8QG+1kInP9vuYvq4LIhQwqjsi5kai6w=
  • Ironport-hdrordr: A9a23:hTvxHKtBDPbmwiT4hmtUXel37skDctV00zEX/kB9WHVpm6uj5q eTdZUgpHvJYVMqM03I9urtBEDtexzhHP1OgbX5X43NYOCOggLBRuxfBODZogHIKmnT8fNcyL clU4UWMqyUMbGit7eY3OBvKadD/OW6
  • Ironport-sdr: IxZho07Rll2YSGepH2CpjA7ZrHnGW7+Wu9e/OZtqDVRSaxmQn0bGbK/W6ayDVqigq3Jh0Lu57R 9JXjGwU9Wm36KtXNzW2LDhOpsI82XIgTsOs+DZfNGa1DUj4dd670f3rtVOKindecrjilAKs+F8 FERkUavgfquhbFZZYLSa6mhtCQ1g2E8uk8zkh4hUxemm/vTlMULR1eCnhsI2jxwxy3YEEEEW+V nQ9pM4KSqub1Dh0eV/SH5MmXLBLOYRVI6OdCMFOMZKuvbJNkqX5p6yFY77Vrlp/lfh6MQxZ5zr qjRIa2WlXFi0uTDblZeESA09
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Oct 18, 2021 at 04:37:27PM +0200, Jan Beulich wrote:
> On 18.10.2021 16:26, Roger Pau Monné wrote:
> > On Wed, Sep 29, 2021 at 11:42:54AM +0200, Jan Beulich wrote:
> >> While it was me to add them, I'm afraid I don't see justification for
> >> the assertions: A vCPU may very well have got preempted while in user
> >> mode. Limit compat guest user mode stack dumps to the containing page
> >> (like is done when using do_page_walk()), and suppress their dumping
> >> altogether for 64-bit Dom0.
> > 
> > I'm slightly lost by this last sentence...
> > 
> >> @@ -328,7 +329,12 @@ static void show_guest_stack(struct vcpu
> >>      {
> >>          struct vcpu *vcpu;
> >>  
> >> -        ASSERT(guest_kernel_mode(v, regs));
> >> +        if ( !guest_kernel_mode(v, regs) )
> >> +        {
> >> +            printk("User mode stack\n");
> >> +            return;
> >> +        }
> > 
> > ...as you seem to unconditionally prevent the dump regardless of
> > whether it's dom0 or domU as long as it's not a kernel stack?
> 
> Well, Dom0 comes into play by way of me talking about debug key '0'.
> I've replaced "Dom0" by "domains" in the sentence.

Thanks, with that:

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> > I assume when running in PV 64bit mode user-space could be executing a
> > 32bit program and hence Xen could then misprint the stack as a 64bit
> > one?
> 
> That's not a primary concern, I would think. The real problem is
> do_page_walk() doing
> 
>     unsigned long mfn = pagetable_get_pfn(v->arch.guest_table);
> 
> first thing: No consideration of guest user mode here at all. And
> I didn't want to teach it without real need.

Oh, indeed. It would need to use guest_table_user at least.

Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.