On Thu, 2 Jun 2016, Martin Cerveny wrote:
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 05:01 PM, Martin Cerveny wrote:
Hello.
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 12:23 PM, Martin Cerveny wrote:
:-(
On Wed, 1 Jun 2016, Martin Cerveny wrote:
I hit proba
On 01/06/16 17:12, Martin Cerveny wrote:
> Hello.
>
> I hit probably the same error with released "XenServer 7.0".
> - I have Xen4.6.1 (commit d77bac5c064ffb9dbb5b89b55b89853f1b784ebf -
> update Xen version to 4.6.1)
> - XS7 (Dundee) beta3 (kernel-3.10.96-479.383024.x86_64.rpm) work OK
> - XS7 rel
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 05:01 PM, Martin Cerveny wrote:
Hello.
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 12:23 PM, Martin Cerveny wrote:
:-(
On Wed, 1 Jun 2016, Martin Cerveny wrote:
I hit probably the same error with released "XenServer 7.
On 06/01/2016 05:01 PM, Martin Cerveny wrote:
> Hello.
>
> On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
>> On 06/01/2016 12:23 PM, Martin Cerveny wrote:
>>> :-(
>>>
>>> On Wed, 1 Jun 2016, Martin Cerveny wrote:
I hit probably the same error with released "XenServer 7.0".
- I have Xen4.6.1 (
Hello.
On Wed, 1 Jun 2016, Boris Ostrovsky wrote:
On 06/01/2016 12:23 PM, Martin Cerveny wrote:
:-(
On Wed, 1 Jun 2016, Martin Cerveny wrote:
I hit probably the same error with released "XenServer 7.0".
- I have Xen4.6.1 (commit d77bac5c064ffb9dbb5b89b55b89853f1b784ebf -
update Xen version to
On 06/01/2016 12:23 PM, Martin Cerveny wrote:
> :-(
>
> On Wed, 1 Jun 2016, Martin Cerveny wrote:
>> I hit probably the same error with released "XenServer 7.0".
>> - I have Xen4.6.1 (commit d77bac5c064ffb9dbb5b89b55b89853f1b784ebf -
>> update Xen version to 4.6.1)
>> - XS7 (Dundee) beta3 (kernel-3
:-(
On Wed, 1 Jun 2016, Martin Cerveny wrote:
I hit probably the same error with released "XenServer 7.0".
- I have Xen4.6.1 (commit d77bac5c064ffb9dbb5b89b55b89853f1b784ebf - update
Xen version to 4.6.1)
- XS7 (Dundee) beta3 (kernel-3.10.96-479.383024.x86_64.rpm) work OK
- XS7 release (kernel
Hello.
I hit probably the same error with released "XenServer 7.0".
- I have Xen4.6.1 (commit d77bac5c064ffb9dbb5b89b55b89853f1b784ebf - update Xen
version to 4.6.1)
- XS7 (Dundee) beta3 (kernel-3.10.96-479.383024.x86_64.rpm) work OK
- XS7 release (kernel-3.10.96-484.383030.x86_64.rpm) crash
- p
On 26/05/16 15:05, Boris Ostrovsky wrote:
> On 05/26/2016 06:24 AM, David Vrabel wrote:
>>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>>> pte_t pte)
>>> * page tables for mapping the p2m list, too, and page tables MUST be
>>> * mapped read-only.
>>> */
>>>
On 05/26/2016 06:24 AM, David Vrabel wrote:
>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
>> pte_t pte)
>> * page tables for mapping the p2m list, too, and page tables MUST be
>> * mapped read-only.
>> */
>> -pfn = pte_pfn(pte);
>> +pfn = (pte & P
On 17/05/16 16:11, David Vrabel wrote:
> On 11/05/16 11:16, David Vrabel wrote:
>>
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it up afterwards.
>
> Kevin, can you try this patch.
>
> David
>
> 8<-
> x86/xe
On 05/17/2016 09:11 AM, David Vrabel wrote:
> On 11/05/16 11:16, David Vrabel wrote:
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it up afterwards.
> Kevin, can you try this patch.
Yes :D. The patch is working fine.
I only g
On 11/05/16 11:16, David Vrabel wrote:
>
> Why don't we get the RW bits correct when making the pteval when we
> already have the pfn, instead trying to fix it up afterwards.
Kevin, can you try this patch.
David
8<-
x86/xen: avoid m2p lookup when setting early page table entries
Hi Boris,
On 05/10/2016 02:11 PM, Boris Ostrovsky wrote:
> On 05/10/2016 12:11 PM, Kevin Moraga wrote:
> Can you boot your system bare-metal and post output of 'biosdecode' command?
>
> -boris
Sure, it's attached.
--
Sincerely,
Kevin Moraga
PGP: F258EDCB
Fingerprint: 3915 A5A9 959C D18F 0A89 B47
On 11/05/16 14:48, David Vrabel wrote:
> On 11/05/16 13:21, Jan Beulich wrote:
> On 11.05.16 at 12:16, wrote:
>>> On 11/05/16 08:00, Juergen Gross wrote:
Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>>
>>> Why don't we get the RW bits correct when making the pteval when we
>>>
>>> On 11.05.16 at 14:48, wrote:
> On 11/05/16 13:21, Jan Beulich wrote:
> On 11.05.16 at 12:16, wrote:
>>> On 11/05/16 08:00, Juergen Gross wrote:
Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>>
>>> Why don't we get the RW bits correct when making the pteval when we
>>> alrea
On 11/05/16 13:21, Jan Beulich wrote:
On 11.05.16 at 12:16, wrote:
>> On 11/05/16 08:00, Juergen Gross wrote:
>>> Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it
>>> On 11.05.16 at 12:16, wrote:
> On 11/05/16 08:00, Juergen Gross wrote:
>> Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>
> Why don't we get the RW bits correct when making the pteval when we
> already have the pfn, instead trying to fix it up afterwards.
While it looks like this wo
>>> On 11.05.16 at 12:10, wrote:
> On 11/05/16 12:03, Jan Beulich wrote:
> On 11.05.16 at 11:57, wrote:
>>> On 11/05/16 09:15, Jan Beulich wrote:
>>> On 11.05.16 at 09:00, wrote:
> Having a Xen specific pte flag seems to be much more intrusive than
> having an early boot page fau
On 11/05/16 08:00, Juergen Gross wrote:
> On 11/05/16 08:35, Jan Beulich wrote:
> On 11.05.16 at 07:49, wrote:
>>> On 10/05/16 18:35, Boris Ostrovsky wrote:
On 05/10/2016 11:43 AM, Juergen Gross wrote:
> On 10/05/16 17:35, Jan Beulich wrote:
> On 10.05.16 at 17:19, wrote:
>>>
On 11/05/16 12:03, Jan Beulich wrote:
On 11.05.16 at 11:57, wrote:
>> On 11/05/16 09:15, Jan Beulich wrote:
>> On 11.05.16 at 09:00, wrote:
Having a Xen specific pte flag seems to be much more intrusive than
having an early boot page fault handler consisting of just one line
>>
>>> On 11.05.16 at 11:57, wrote:
> On 11/05/16 09:15, Jan Beulich wrote:
> On 11.05.16 at 09:00, wrote:
>>> Having a Xen specific pte flag seems to be much more intrusive than
>>> having an early boot page fault handler consisting of just one line
>>> being capable to mimic the default handle
On 11/05/16 09:15, Jan Beulich wrote:
On 11.05.16 at 09:00, wrote:
>> Having a Xen specific pte flag seems to be much more intrusive than
>> having an early boot page fault handler consisting of just one line
>> being capable to mimic the default handler in just one aspect (see
>> attached pa
>>> On 11.05.16 at 09:00, wrote:
> Having a Xen specific pte flag seems to be much more intrusive than
> having an early boot page fault handler consisting of just one line
> being capable to mimic the default handler in just one aspect (see
> attached patch - only compile tested).
Well, this sim
On 11/05/16 08:35, Jan Beulich wrote:
On 11.05.16 at 07:49, wrote:
>> On 10/05/16 18:35, Boris Ostrovsky wrote:
>>> On 05/10/2016 11:43 AM, Juergen Gross wrote:
On 10/05/16 17:35, Jan Beulich wrote:
On 10.05.16 at 17:19, wrote:
>> On 10/05/16 15:57, Jan Beulich wrote:
>
>>> On 11.05.16 at 07:49, wrote:
> On 10/05/16 18:35, Boris Ostrovsky wrote:
>> On 05/10/2016 11:43 AM, Juergen Gross wrote:
>>> On 10/05/16 17:35, Jan Beulich wrote:
>>> On 10.05.16 at 17:19, wrote:
> On 10/05/16 15:57, Jan Beulich wrote:
> On 10.05.16 at 15:39, wrote:
>>> I
On 10/05/16 18:35, Boris Ostrovsky wrote:
> On 05/10/2016 11:43 AM, Juergen Gross wrote:
>> On 10/05/16 17:35, Jan Beulich wrote:
>> On 10.05.16 at 17:19, wrote:
On 10/05/16 15:57, Jan Beulich wrote:
On 10.05.16 at 15:39, wrote:
>> I didn't finish unwrapping the stack yester
On 05/10/2016 12:11 PM, Kevin Moraga wrote:
>
Can you boot your system bare-metal and post output of 'biosdecode' command?
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 05/10/2016 11:43 AM, Juergen Gross wrote:
> On 10/05/16 17:35, Jan Beulich wrote:
> On 10.05.16 at 17:19, wrote:
>>> On 10/05/16 15:57, Jan Beulich wrote:
>>> On 10.05.16 at 15:39, wrote:
> I didn't finish unwrapping the stack yesterday. Here it is:
>
> setup_arch -> dmi_sc
On 05/10/2016 01:23 AM, Jan Beulich wrote:
On 09.05.16 at 20:40, wrote:
>> On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>>> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
On 05/09/2016 12:40 PM, Kevin Moraga wrote:
> On 05/09/2016 09:53 AM, Jan Beulich wrote:
> On 09.05.16 a
On 10/05/16 17:35, Jan Beulich wrote:
On 10.05.16 at 17:19, wrote:
>> On 10/05/16 15:57, Jan Beulich wrote:
>> On 10.05.16 at 15:39, wrote:
I didn't finish unwrapping the stack yesterday. Here it is:
setup_arch -> dmi_scan_machine -> dmi_walk_early -> early_ioremap
>>>
>>>
>>> On 10.05.16 at 17:19, wrote:
> On 10/05/16 15:57, Jan Beulich wrote:
> On 10.05.16 at 15:39, wrote:
>>> I didn't finish unwrapping the stack yesterday. Here it is:
>>>
>>> setup_arch -> dmi_scan_machine -> dmi_walk_early -> early_ioremap
>>
>> Ah, that makes sense. Yet why would early_io
On 10/05/16 15:57, Jan Beulich wrote:
On 10.05.16 at 15:39, wrote:
>> I didn't finish unwrapping the stack yesterday. Here it is:
>>
>> setup_arch -> dmi_scan_machine -> dmi_walk_early -> early_ioremap
>
> Ah, that makes sense. Yet why would early_ioremap() involve an
> M2P lookup? As said,
>>> On 10.05.16 at 15:39, wrote:
> I didn't finish unwrapping the stack yesterday. Here it is:
>
> setup_arch -> dmi_scan_machine -> dmi_walk_early -> early_ioremap
Ah, that makes sense. Yet why would early_ioremap() involve an
M2P lookup? As said, MMIO addresses shouldn't be subject to such
loo
On 05/10/2016 03:23 AM, Jan Beulich wrote:
On 09.05.16 at 20:40, wrote:
>> On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>>> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
On 05/09/2016 12:40 PM, Kevin Moraga wrote:
> On 05/09/2016 09:53 AM, Jan Beulich wrote:
> On 09.05.16 at
>>> On 09.05.16 at 20:40, wrote:
> On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>>
>> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
>>> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
On 05/09/2016 09:53 AM, Jan Beulich wrote:
On 09.05.16 at 16:52, wrote:
>> On 05/09/2016 04:08 AM,
On 05/09/2016 01:22 PM, Kevin Moraga wrote:
>
> On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
>> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>>> On 05/09/2016 09:53 AM, Jan Beulich wrote:
>>> On 09.05.16 at 16:52, wrote:
> On 05/09/2016 04:08 AM, Jan Beulich wrote:
> On 09.05.16 a
On 05/09/2016 11:15 AM, Boris Ostrovsky wrote:
> On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>> On 05/09/2016 09:53 AM, Jan Beulich wrote:
>> On 09.05.16 at 16:52, wrote:
On 05/09/2016 04:08 AM, Jan Beulich wrote:
On 09.05.16 at 00:51, wrote:
>> I'm try to compile kernel 4
On 05/09/2016 12:40 PM, Kevin Moraga wrote:
>
> On 05/09/2016 09:53 AM, Jan Beulich wrote:
> On 09.05.16 at 16:52, wrote:
>>> On 05/09/2016 04:08 AM, Jan Beulich wrote:
>>> On 09.05.16 at 00:51, wrote:
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and
On 05/09/2016 09:53 AM, Jan Beulich wrote:
On 09.05.16 at 16:52, wrote:
>> On 05/09/2016 04:08 AM, Jan Beulich wrote:
>> On 09.05.16 at 00:51, wrote:
I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
and Intel Skylake processor (Intel Core i7-6600U)
>>> On 09.05.16 at 16:52, wrote:
> On 05/09/2016 04:08 AM, Jan Beulich wrote:
> On 09.05.16 at 00:51, wrote:
>>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
>>> and Intel Skylake processor (Intel Core i7-6600U)
>>>
>>> This kernel is crashing almost in the same way
On 05/09/2016 04:08 AM, Jan Beulich wrote:
On 09.05.16 at 00:51, wrote:
>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
>> and Intel Skylake processor (Intel Core i7-6600U)
>>
>> This kernel is crashing almost in the same way as explained in this
>> thread... But my
>>> On 09.05.16 at 00:51, wrote:
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and Intel Skylake processor (Intel Core i7-6600U)
>
> This kernel is crashing almost in the same way as explained in this
> thread... But my problem is mainly with Skylake. Because the sam
>>> On 09.05.16 at 09:23, wrote:
> On 08/05/2016 23:51, Kevin Moraga wrote:
>> Hi,
>> I don't know if this is the exact same issue... but is the most related
>> one that I found.
>>
>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
>> and Intel Skylake processor (Intel Cor
On 08/05/2016 23:51, Kevin Moraga wrote:
> Hi,
> I don't know if this is the exact same issue... but is the most related
> one that I found.
>
> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
> and Intel Skylake processor (Intel Core i7-6600U)
>
> This kernel is crashing al
Hi,
I don't know if this is the exact same issue... but is the most related
one that I found.
I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0
and Intel Skylake processor (Intel Core i7-6600U)
This kernel is crashing almost in the same way as explained in this
thread... But
On Mon, Mar 28, 2016 at 06:00:33PM +0100, Michael Young wrote:
> I get a crash on boot with my Fedora xen-4.6.1-3.fc24 packages. This seems
> to be related to how it is compiled because the same code compiled under
> Fedora 23 works. The boot logs are attached. The address mentioned in the
> crash
>>> On 28.03.16 at 19:00, wrote:
> I get a crash on boot with my Fedora xen-4.6.1-3.fc24 packages. This seems
> to be related to how it is compiled because the same code compiled under
> Fedora 23 works. The boot logs are attached. The address mentioned in the
> crash has the code
> 0x8
48 matches
Mail list logo