On 11/12/2020 11:15, Manuel Bouyer wrote:
> On Fri, Dec 11, 2020 at 09:58:54AM +0100, Jan Beulich wrote:
>> Could you please revert 9ff970564764 ("x86/mm: drop guest_get_eff_l1e()")?
>> I think there was a thinko there in that the change can't be split from
>> the bigger one which was part of the o
On Fri, Dec 11, 2020 at 09:58:54AM +0100, Jan Beulich wrote:
> Could you please revert 9ff970564764 ("x86/mm: drop guest_get_eff_l1e()")?
> I think there was a thinko there in that the change can't be split from
> the bigger one which was part of the originally planned set for XSA-286.
> We mustn't
On Thu, Dec 10, 2020 at 09:01:12PM +, Andrew Cooper wrote:
> I've repro'd the problem.
>
> When I modify Xen to explicitly demand-map the LDT in the MMUEXT_SET_LDT
> hypercall, everything works fine.
>
> Specifically, this delta:
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index
On 10.12.2020 10:51, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 07:08:41PM +, Andrew Cooper wrote:
>> Oh of course - we don't follow the exit-to-guest path on the way out here.
>>
>> As a gross hack to check that we've at least diagnosed the issue
>> appropriately, could you modify NetBSD t
On 10/12/2020 17:35, Manuel Bouyer wrote:
> On Thu, Dec 10, 2020 at 05:18:39PM +, Andrew Cooper wrote:
>> However, Xen finds the mapping not-present when trying to demand-map it,
>> hence why the #PF is forwarded to the kernel.
>>
>> The way we pull guest virtual addresses was altered by XSA-28
On Thu, Dec 10, 2020 at 05:18:39PM +, Andrew Cooper wrote:
> The debugging earlier shows that MMUEXT_SET_LDT has indeed been called.
> Presumably 0xbd00a000 is a plausible virtual address for NetBSD
> to position the LDT?
Yes, it is.
>
> However, Xen finds the mapping not-present w
On 10/12/2020 17:03, Manuel Bouyer wrote:
> On Thu, Dec 10, 2020 at 03:51:46PM +, Andrew Cooper wrote:
>>> [ 7.6617663] cs 0x47 ds 0x23 es 0x23 fs gs ss 0x3f
>>> [ 7.7345663] fsbase 00 gsbase 00
>>>
>>> so it looks like something resets %fs to
On Thu, Dec 10, 2020 at 03:51:46PM +, Andrew Cooper wrote:
> > [ 7.6617663] cs 0x47 ds 0x23 es 0x23 fs gs ss 0x3f
> > [ 7.7345663] fsbase 00 gsbase 00
> >
> > so it looks like something resets %fs to 0 ...
> >
> > Anyway the fault address 0xfff
On 10/12/2020 09:51, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 07:08:41PM +, Andrew Cooper wrote:
>> Oh of course - we don't follow the exit-to-guest path on the way out here.
>>
>> As a gross hack to check that we've at least diagnosed the issue
>> appropriately, could you modify NetBSD t
On 10.12.2020 10:51, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 07:08:41PM +, Andrew Cooper wrote:
>> Oh of course - we don't follow the exit-to-guest path on the way out here.
>>
>> As a gross hack to check that we've at least diagnosed the issue
>> appropriately, could you modify NetBSD t
On Wed, Dec 09, 2020 at 07:08:41PM +, Andrew Cooper wrote:
> Oh of course - we don't follow the exit-to-guest path on the way out here.
>
> As a gross hack to check that we've at least diagnosed the issue
> appropriately, could you modify NetBSD to explicitly load the %ss
> selector into %es (
On 09/12/2020 18:57, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 06:08:53PM +, Andrew Cooper wrote:
>> On 09/12/2020 16:30, Manuel Bouyer wrote:
>>> On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
[...]
>> I wonder if the LDT is set up correctly.
> I guess it is,
On Wed, Dec 09, 2020 at 06:08:53PM +, Andrew Cooper wrote:
> On 09/12/2020 16:30, Manuel Bouyer wrote:
> > On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
> >> [...]
> I wonder if the LDT is set up correctly.
> >>> I guess it is, otherwise it wouldn't boot with a Xen 4.13 ke
On 09/12/2020 16:30, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
>> [...]
I wonder if the LDT is set up correctly.
>>> I guess it is, otherwise it wouldn't boot with a Xen 4.13 kernel, isn't it ?
>> Well - you said you always saw it once on 4.13, which
On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
> [...]
> >> I wonder if the LDT is set up correctly.
> > I guess it is, otherwise it wouldn't boot with a Xen 4.13 kernel, isn't it ?
>
> Well - you said you always saw it once on 4.13, which clearly shows that
> something was wonky,
On 09/12/2020 15:44, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 02:41:23PM +, Andrew Cooper wrote:
>> Huh, so it is the LDT, but we're not getting as far as inspecting the
>> target frame.
>>
>> I wonder if the LDT is set up correctly.
> I guess it is, otherwise it wouldn't boot with a Xen
On Wed, Dec 09, 2020 at 02:41:23PM +, Andrew Cooper wrote:
>
> Huh, so it is the LDT, but we're not getting as far as inspecting the
> target frame.
>
> I wonder if the LDT is set up correctly.
I guess it is, otherwise it wouldn't boot with a Xen 4.13 kernel, isn't it ?
> How about this inc
On 09/12/2020 13:59, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 01:28:54PM +, Andrew Cooper wrote:
>> Pagefaults on IRET come either from stack accesses for operands (not the
>> case here as Xen is otherwise working fine), or from segement selector
>> loads for %cs and %ss.
>>
>> In this ex
On Wed, Dec 09, 2020 at 01:28:54PM +, Andrew Cooper wrote:
>
> Pagefaults on IRET come either from stack accesses for operands (not the
> case here as Xen is otherwise working fine), or from segement selector
> loads for %cs and %ss.
>
> In this example, %ss is in the LDT, which specifically
On 09/12/2020 10:15, Manuel Bouyer wrote:
> On Tue, Dec 08, 2020 at 06:13:46PM +, Andrew Cooper wrote:
>> On 08/12/2020 17:57, Manuel Bouyer wrote:
>>> Hello,
>>> for the first time I tried to boot a xen kernel from devel with
>>> a NetBSD PV dom0. The kernel boots, but when the first userland
On Tue, Dec 08, 2020 at 06:13:46PM +, Andrew Cooper wrote:
> On 08/12/2020 17:57, Manuel Bouyer wrote:
> > Hello,
> > for the first time I tried to boot a xen kernel from devel with
> > a NetBSD PV dom0. The kernel boots, but when the first userland prcess
> > is launched, it seems to enter a l
On Wed, Dec 09, 2020 at 09:39:49AM +0100, Jan Beulich wrote:
> On 08.12.2020 19:13, Andrew Cooper wrote:
> > On 08/12/2020 17:57, Manuel Bouyer wrote:
> >> Hello,
> >> for the first time I tried to boot a xen kernel from devel with
> >> a NetBSD PV dom0. The kernel boots, but when the first userlan
On 08.12.2020 19:13, Andrew Cooper wrote:
> On 08/12/2020 17:57, Manuel Bouyer wrote:
>> Hello,
>> for the first time I tried to boot a xen kernel from devel with
>> a NetBSD PV dom0. The kernel boots, but when the first userland prcess
>> is launched, it seems to enter a loop involving search_pre_
On 08/12/2020 17:57, Manuel Bouyer wrote:
> Hello,
> for the first time I tried to boot a xen kernel from devel with
> a NetBSD PV dom0. The kernel boots, but when the first userland prcess
> is launched, it seems to enter a loop involving search_pre_exception_table()
> (I see an endless stream fro
24 matches
Mail list logo
