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
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
0x82d08023d3c3 :
je 0x82d08023e90a
49 matches
Mail list logo
