From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/PV: properly populate descriptor tables Date: Wed, 23 Sep 2015 16:47:14 +0100 Message-ID: <5602C982.6050905@citrix.com> References: <5602E29802000078000A4EAF@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZemGQ-0003EK-9m for xen-devel@lists.xenproject.org; Wed, 23 Sep 2015 15:47:22 +0000 In-Reply-To: <5602E29802000078000A4EAF@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: Wei Liu , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 23/09/15 16:34, Jan Beulich wrote: > Us extending the GDT limit past the Xen descriptors so far meant that > guests (including user mode programs) accessing any descriptor table > slot above the original OS'es limit but below the first Xen descriptor > caused a #PF, converted to a #GP in our #PF handler. Which is quite > different from the native behavior, where some of such accesses (LAR > and LSL) don't fault. Mimic that behavior by mapping a blank page into > unused slots. > > While not strictly required, treat the LDT the same for consistency. > > Reported-by: Andrew Cooper > Signed-off-by: Jan Beulich Oh - thanks for doing this. (Luckily, I hadn't yet had enough time to look into it.) Reviewed-by: Andrew Cooper > --- > Not sure about 4.6 here: Beyond Andrew noticing I don't think anyone > ran into this issue in a real world environment, and hence it doesn't > seem to be too critical to get this fixed. This bug causes unexpected #GP faults being handed to PV guests which would not occur on native, when using the `lsl` and `lsr` instructions. I expect it is the rarity of those instructions which is why this has gone unnoticed for so long. It probably should be backported. ~Andrew