xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* identify a Xen PV domU to fix devmem_is_allowed
@ 2016-02-29 10:28 Olaf Hering
  2016-02-29 15:10 ` Konrad Rzeszutek Wilk
  2016-03-01 15:29 ` David Vrabel
  0 siblings, 2 replies; 16+ messages in thread
From: Olaf Hering @ 2016-02-29 10:28 UTC (permalink / raw)
  To: xen-devel

What is the correct way to identify a Xen PV domU in the kenrel?
devmem_is_allowed() used to disable access to pages < 256 in domU.
With pvops this check was removed, or never ported forward.

Would this change be the correct fix?

+++ b/arch/x86/mm/init.c
@@ -637,7 +637,7 @@ void __init init_mem_mapping(void)
 int devmem_is_allowed(unsigned long pagenr)
 {
        if (pagenr < 256)
-               return 1;
+               return !xen_pv_domain();
        if (iomem_is_exclusive(pagenr << PAGE_SHIFT))
                return 0;
        if (!page_is_ram(pagenr))

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 10:28 identify a Xen PV domU to fix devmem_is_allowed Olaf Hering
@ 2016-02-29 15:10 ` Konrad Rzeszutek Wilk
  2016-02-29 15:29   ` Olaf Hering
                     ` (2 more replies)
  2016-03-01 15:29 ` David Vrabel
  1 sibling, 3 replies; 16+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-02-29 15:10 UTC (permalink / raw)
  To: Olaf Hering, boris.ostrovsky, david.vrabel; +Cc: xen-devel

On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
> What is the correct way to identify a Xen PV domU in the kenrel?
> devmem_is_allowed() used to disable access to pages < 256 in domU.
> With pvops this check was removed, or never ported forward.

CC-ing Boris and Daniel.

Why is this needed? The first 640KB of memory in a guest are
RAM pages with no BIOS data in it.

> 
> Would this change be the correct fix?

.. A fix for what issue?
> 
> +++ b/arch/x86/mm/init.c
> @@ -637,7 +637,7 @@ void __init init_mem_mapping(void)
>  int devmem_is_allowed(unsigned long pagenr)
>  {
>         if (pagenr < 256)
> -               return 1;
> +               return !xen_pv_domain();
>         if (iomem_is_exclusive(pagenr << PAGE_SHIFT))
>                 return 0;
>         if (!page_is_ram(pagenr))
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 15:10 ` Konrad Rzeszutek Wilk
@ 2016-02-29 15:29   ` Olaf Hering
  2016-02-29 18:32     ` Boris Ostrovsky
  2016-03-01 10:38   ` Jan Beulich
  2016-03-01 16:23   ` Olaf Hering
  2 siblings, 1 reply; 16+ messages in thread
From: Olaf Hering @ 2016-02-29 15:29 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: boris.ostrovsky, david.vrabel, xen-devel

On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:

> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
> > Would this change be the correct fix?
> .. A fix for what issue?

mmap returns some pointer, but appearently that memory can not be used.

https://bugzilla.suse.com/show_bug.cgi?id=964342

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 15:29   ` Olaf Hering
@ 2016-02-29 18:32     ` Boris Ostrovsky
  2016-03-01 15:14       ` Olaf Hering
  0 siblings, 1 reply; 16+ messages in thread
From: Boris Ostrovsky @ 2016-02-29 18:32 UTC (permalink / raw)
  To: Olaf Hering, Konrad Rzeszutek Wilk; +Cc: david.vrabel, xen-devel

On 02/29/2016 10:29 AM, Olaf Hering wrote:
> On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:
>
>> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
>>> Would this change be the correct fix?
>> .. A fix for what issue?
> mmap returns some pointer, but appearently that memory can not be used.
>
> https://bugzilla.suse.com/show_bug.cgi?id=964342
>
> Olaf

Do you see any messages in hypervisor log (like "Bad L1 flags 10")?

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 15:10 ` Konrad Rzeszutek Wilk
  2016-02-29 15:29   ` Olaf Hering
@ 2016-03-01 10:38   ` Jan Beulich
  2016-03-01 14:34     ` Konrad Rzeszutek Wilk
  2016-03-01 16:23   ` Olaf Hering
  2 siblings, 1 reply; 16+ messages in thread
From: Jan Beulich @ 2016-03-01 10:38 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: boris.ostrovsky, Olaf Hering, david.vrabel, xen-devel

>>> On 29.02.16 at 16:10, <konrad.wilk@oracle.com> wrote:
> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
>> What is the correct way to identify a Xen PV domU in the kenrel?
>> devmem_is_allowed() used to disable access to pages < 256 in domU.
>> With pvops this check was removed, or never ported forward.
> 
> CC-ing Boris and Daniel.
> 
> Why is this needed? The first 640KB of memory in a guest are
> RAM pages with no BIOS data in it.

Exactly: devmem_is_allowed() is specifically meant to return true
if and only if the page is not RAM or otherwise special. The
question just is whether what Olaf suggested is also correct for
Dom0 - I don't recall whether the low 1Mb gets 1:1 mapped in
that case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-01 10:38   ` Jan Beulich
@ 2016-03-01 14:34     ` Konrad Rzeszutek Wilk
  2016-03-01 14:45       ` Boris Ostrovsky
  0 siblings, 1 reply; 16+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-01 14:34 UTC (permalink / raw)
  To: Jan Beulich; +Cc: boris.ostrovsky, Olaf Hering, david.vrabel, xen-devel

On Tue, Mar 01, 2016 at 03:38:55AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 16:10, <konrad.wilk@oracle.com> wrote:
> > On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
> >> What is the correct way to identify a Xen PV domU in the kenrel?
> >> devmem_is_allowed() used to disable access to pages < 256 in domU.
> >> With pvops this check was removed, or never ported forward.
> > 
> > CC-ing Boris and Daniel.
> > 
> > Why is this needed? The first 640KB of memory in a guest are
> > RAM pages with no BIOS data in it.
> 
> Exactly: devmem_is_allowed() is specifically meant to return true
> if and only if the page is not RAM or otherwise special. The
> question just is whether what Olaf suggested is also correct for
> Dom0 - I don't recall whether the low 1Mb gets 1:1 mapped in
> that case.

Would it be just better to change that code to scan the E820 instead
of using hard-coded values?

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-01 14:34     ` Konrad Rzeszutek Wilk
@ 2016-03-01 14:45       ` Boris Ostrovsky
  2016-03-15 16:57         ` Olaf Hering
  0 siblings, 1 reply; 16+ messages in thread
From: Boris Ostrovsky @ 2016-03-01 14:45 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk, Jan Beulich; +Cc: Olaf Hering, david.vrabel, xen-devel

On 03/01/2016 09:34 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 01, 2016 at 03:38:55AM -0700, Jan Beulich wrote:
>>>>> On 29.02.16 at 16:10, <konrad.wilk@oracle.com> wrote:
>>> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
>>>> What is the correct way to identify a Xen PV domU in the kenrel?
>>>> devmem_is_allowed() used to disable access to pages < 256 in domU.
>>>> With pvops this check was removed, or never ported forward.
>>> CC-ing Boris and Daniel.
>>>
>>> Why is this needed? The first 640KB of memory in a guest are
>>> RAM pages with no BIOS data in it.
>> Exactly: devmem_is_allowed() is specifically meant to return true
>> if and only if the page is not RAM or otherwise special. The
>> question just is whether what Olaf suggested is also correct for
>> Dom0 - I don't recall whether the low 1Mb gets 1:1 mapped in
>> that case.

I think it is. On dom0:

root@ovs101> od -N 1 -j 4096 /dev/mem
0010000 000000
0010001
root@ovs101>


on domU:

[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
od: /dev/mem: read error: Bad address
0010000
[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#

with

(XEN) mm.c:1767:d14v0 Bad L1 flags 10
(XEN) mm.c:1767:d14v0 Bad L1 flags 10

in the hypervisor log.

IIUIC that's because l1_disallow_mask is more permissive for dom0.



> Would it be just better to change that code to scan the E820 instead
> of using hard-coded values?

trim_bios_range() seems to imply that some BIOSes may present <1MB area 
as RAM. We remove some chunks but not all (i.e. 4K through 640K may 
still be shown as RAM).


-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 18:32     ` Boris Ostrovsky
@ 2016-03-01 15:14       ` Olaf Hering
  0 siblings, 0 replies; 16+ messages in thread
From: Olaf Hering @ 2016-03-01 15:14 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, david.vrabel

On Mon, Feb 29, Boris Ostrovsky wrote:

> Do you see any messages in hypervisor log (like "Bad L1 flags 10")?

Yes, with a debug build of xen.gz.
(XEN) mm.c:1882:d1v0 Bad L1 flags 10

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 10:28 identify a Xen PV domU to fix devmem_is_allowed Olaf Hering
  2016-02-29 15:10 ` Konrad Rzeszutek Wilk
@ 2016-03-01 15:29 ` David Vrabel
  1 sibling, 0 replies; 16+ messages in thread
From: David Vrabel @ 2016-03-01 15:29 UTC (permalink / raw)
  To: Olaf Hering, xen-devel

On 29/02/16 10:28, Olaf Hering wrote:
> What is the correct way to identify a Xen PV domU in the kenrel?
> devmem_is_allowed() used to disable access to pages < 256 in domU.
> With pvops this check was removed, or never ported forward.
> 
> Would this change be the correct fix?

I think the bug is in range_is_allowed() as it is using
devmem_is_allowed() to avoid having to correctly check for aliases.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-02-29 15:10 ` Konrad Rzeszutek Wilk
  2016-02-29 15:29   ` Olaf Hering
  2016-03-01 10:38   ` Jan Beulich
@ 2016-03-01 16:23   ` Olaf Hering
  2 siblings, 0 replies; 16+ messages in thread
From: Olaf Hering @ 2016-03-01 16:23 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: boris.ostrovsky, david.vrabel, xen-devel

On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:

> .. A fix for what issue?

#include <unistd.h>
#include <stdio.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(void)
{
	unsigned long long *p;
	int fd;
	fd = open("/dev/mem", O_RDWR);
	if (fd < 0) {
		perror("/dev/mem");
		return 1;
	}
	p = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, 0);
	if (p != MAP_FAILED) {
		printf("p %p: %016llx\n", p, *p);
		munmap(p, 4096);
	}
	close(fd);
	return 0;
}

# ./t
[ 1627.491281] ------------[ cut here ]------------
[ 1627.491911] WARNING: CPU: 0 PID: 2004 at ../arch/x86/xen/multicalls.c:129 xen_mc_flush+0x1c5/0x1d0()
[ 1627.492739] Modules linked in: dm_mod af_packet iscsi_ibft iscsi_boot_sysfs coretemp crct10dif_pclmul joydev crc32_pclmul crc32c_intel xen_kbdfront xen_fbfront fb_sys_fops syscopyarea sysfillrect sysimgblt xen_netfront aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd pcspkr xen_blkfront sg
[ 1627.494511] CPU: 0 PID: 2004 Comm: t Tainted: G        W       4.4.2-1-default #1
[ 1627.494958]  ffffffff81a47bf1 ffff88000240fc10 ffffffff8137eb99 0000000000000000
[ 1627.495417]  ffff88000240fc48 ffffffff8107c552 ffff88003f80a2e0 0000000000000001
[ 1627.495881]  00007f53e5e81000 0000000000000000 00007f53e5e81000 ffff88000240fc58
[ 1627.496365] Call Trace:
[ 1627.496834]  [<ffffffff8101a095>] try_stack_unwind+0x175/0x190
[ 1627.497315]  [<ffffffff81018fe9>] dump_trace+0x69/0x3a0
[ 1627.497792]  [<ffffffff8101a0fb>] show_trace_log_lvl+0x4b/0x60
[ 1627.498274]  [<ffffffff8101942c>] show_stack_log_lvl+0x10c/0x180
[ 1627.498751]  [<ffffffff8101a195>] show_stack+0x25/0x50
[ 1627.499225]  [<ffffffff8137eb99>] dump_stack+0x4b/0x72
[ 1627.499695]  [<ffffffff8107c552>] warn_slowpath_common+0x82/0xc0
[ 1627.500179]  [<ffffffff8107c64a>] warn_slowpath_null+0x1a/0x20
[ 1627.500652]  [<ffffffff81006b05>] xen_mc_flush+0x1c5/0x1d0
[ 1627.501126]  [<ffffffff81007365>] xen_leave_lazy_mmu+0x15/0x30
[ 1627.501599]  [<ffffffff811b584d>] remap_pfn_range+0x34d/0x430
[ 1627.502078]  [<ffffffff8149518f>] mmap_mem+0xcf/0x120
[ 1627.502552]  [<ffffffff811bbd37>] mmap_region+0x3f7/0x680
[ 1627.503025]  [<ffffffff811bc2f3>] do_mmap+0x333/0x420
[ 1627.503495]  [<ffffffff811a28c1>] vm_mmap_pgoff+0x91/0xc0
[ 1627.503961]  [<ffffffff811ba6cf>] SyS_mmap_pgoff+0x19f/0x260
[ 1627.504437]  [<ffffffff8101c0db>] SyS_mmap+0x1b/0x30
[ 1627.504899]  [<ffffffff816a96f6>] entry_SYSCALL_64_fastpath+0x16/0x75
[ 1627.506910] DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x75
[ 1627.507380] 
[ 1627.507841] Leftover inexact backtrace:
[ 1627.507841] 
[ 1627.508736] ---[ end trace 3451e822401d3468 ]---
[ 1627.509990] audit: type=1701 audit(1456849316.138:97): auid=0 uid=0 gid=0 ses=1 pid=2004 comm="t" exe="/root/t" sig=7
Bus error (core dumped)


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-01 14:45       ` Boris Ostrovsky
@ 2016-03-15 16:57         ` Olaf Hering
  2016-03-15 18:56           ` Boris Ostrovsky
  2016-03-21 21:29           ` Boris Ostrovsky
  0 siblings, 2 replies; 16+ messages in thread
From: Olaf Hering @ 2016-03-15 16:57 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, david.vrabel, Jan Beulich

On Tue, Mar 01, Boris Ostrovsky wrote:

> on domU:
> 
> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
> od: /dev/mem: read error: Bad address
> 0010000
> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
> 
> with
> 
> (XEN) mm.c:1767:d14v0 Bad L1 flags 10

How should we proceed with this bug?


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-15 16:57         ` Olaf Hering
@ 2016-03-15 18:56           ` Boris Ostrovsky
  2016-03-21 21:29           ` Boris Ostrovsky
  1 sibling, 0 replies; 16+ messages in thread
From: Boris Ostrovsky @ 2016-03-15 18:56 UTC (permalink / raw)
  To: Olaf Hering; +Cc: xen-devel, david.vrabel, Jan Beulich

On 03/15/2016 12:57 PM, Olaf Hering wrote:
> On Tue, Mar 01, Boris Ostrovsky wrote:
>
>> on domU:
>>
>> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
>> od: /dev/mem: read error: Bad address
>> 0010000
>> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
>>
>> with
>>
>> (XEN) mm.c:1767:d14v0 Bad L1 flags 10
> How should we proceed with this bug?

Let me look at this next week, I have a few bugs I need to take care of.

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-15 16:57         ` Olaf Hering
  2016-03-15 18:56           ` Boris Ostrovsky
@ 2016-03-21 21:29           ` Boris Ostrovsky
  2016-03-22 18:37             ` Boris Ostrovsky
  1 sibling, 1 reply; 16+ messages in thread
From: Boris Ostrovsky @ 2016-03-21 21:29 UTC (permalink / raw)
  To: Olaf Hering; +Cc: xen-devel, david.vrabel, Jan Beulich

On 03/15/2016 12:57 PM, Olaf Hering wrote:
> On Tue, Mar 01, Boris Ostrovsky wrote:
>
>> on domU:
>>
>> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 /dev/mem
>> od: /dev/mem: read error: Bad address
>> 0010000
>> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
>>
>> with
>>
>> (XEN) mm.c:1767:d14v0 Bad L1 flags 10
> How should we proceed with this bug?
>

I can't see any way to avoid calling xen_pv_domain() so what you 
suggested should work. The only problem is that this will now cause 
reserved areas to also return 0:

# head /proc/iomem
00000000-00000fff : reserved <====
00001000-0009ffff : System RAM
000a0000-000fffff : reserved       <=====
   000f0000-000fffff : System ROM
00100000-7fffffff : System RAM
   01000000-0172a065 : Kernel code
   0172a066-01d32b3f : Kernel data
   01ec5000-02026fff : Kernel bss
fee00000-fee00fff : Local APIC

which I don't think they really should.

How about this:

     if (pagenr < 256 && !xen_pv_domain())
         return 1;
     if (iomem_is_exclusive(pagenr << PAGE_SHIFT))
         return 0;
     if (!page_is_ram(pagenr))
         return 1;


Also, while looking into this I noticed that pat_x_mtrr_type() will make 
us switch from _PAGE_CACHE_MODE_WB to _PAGE_CACHE_MODE_UC_MINUS when 
trying to mmap and this is what causes the hypervisor error message and 
the splat in Linux. We make this switch despite the fact that MTRR is 
disabled and therefore mtrr_type_lookup() returns MTRR_TYPE_INVALID.

Should we return req_type is MTRR is disabled?

-boris





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-21 21:29           ` Boris Ostrovsky
@ 2016-03-22 18:37             ` Boris Ostrovsky
  2016-03-23  8:28               ` Olaf Hering
  2016-06-06 21:17               ` Olaf Hering
  0 siblings, 2 replies; 16+ messages in thread
From: Boris Ostrovsky @ 2016-03-22 18:37 UTC (permalink / raw)
  To: Olaf Hering; +Cc: xen-devel, david.vrabel, Jan Beulich

On 03/21/2016 05:29 PM, Boris Ostrovsky wrote:
> On 03/15/2016 12:57 PM, Olaf Hering wrote:
>> On Tue, Mar 01, Boris Ostrovsky wrote:
>>
>>> on domU:
>>>
>>> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# od -N 1 -j 4096 
>>> /dev/mem
>>> od: /dev/mem: read error: Bad address
>>> 0010000
>>> [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#
>>>
>>> with
>>>
>>> (XEN) mm.c:1767:d14v0 Bad L1 flags 10
>> How should we proceed with this bug?
>>
>
> I can't see any way to avoid calling xen_pv_domain() so what you 
> suggested should work. The only problem is that this will now cause 
> reserved areas to also return 0:
>
> # head /proc/iomem
> 00000000-00000fff : reserved <====
> 00001000-0009ffff : System RAM
> 000a0000-000fffff : reserved       <=====
>   000f0000-000fffff : System ROM
> 00100000-7fffffff : System RAM
>   01000000-0172a065 : Kernel code
>   0172a066-01d32b3f : Kernel data
>   01ec5000-02026fff : Kernel bss
> fee00000-fee00fff : Local APIC
>
> which I don't think they really should.
>
> How about this:
>
>     if (pagenr < 256 && !xen_pv_domain())
>         return 1;
>     if (iomem_is_exclusive(pagenr << PAGE_SHIFT))
>         return 0;
>     if (!page_is_ram(pagenr))
>         return 1;
>
>
> Also, while looking into this I noticed that pat_x_mtrr_type() will 
> make us switch from _PAGE_CACHE_MODE_WB to _PAGE_CACHE_MODE_UC_MINUS 
> when trying to mmap and this is what causes the hypervisor error 
> message and the splat in Linux. We make this switch despite the fact 
> that MTRR is disabled and therefore mtrr_type_lookup() returns 
> MTRR_TYPE_INVALID.
>
> Should we return req_type is MTRR is disabled?

Olaf,


Can you apply PAT changes from 
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02127.html and 
see if it helps?

It should at least get rid of the splat (patch 3 is the one addresses 
no-MTRR problem that I mentioned above). We should still fix 
devmem_is_allowed() though.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-22 18:37             ` Boris Ostrovsky
@ 2016-03-23  8:28               ` Olaf Hering
  2016-06-06 21:17               ` Olaf Hering
  1 sibling, 0 replies; 16+ messages in thread
From: Olaf Hering @ 2016-03-23  8:28 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: xen-devel, david.vrabel, Jan Beulich

On Tue, Mar 22, Boris Ostrovsky wrote:

> Can you apply PAT changes from
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02127.html
> and see if it helps?

I will try, thanks.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: identify a Xen PV domU to fix devmem_is_allowed
  2016-03-22 18:37             ` Boris Ostrovsky
  2016-03-23  8:28               ` Olaf Hering
@ 2016-06-06 21:17               ` Olaf Hering
  1 sibling, 0 replies; 16+ messages in thread
From: Olaf Hering @ 2016-06-06 21:17 UTC (permalink / raw)
  To: Boris Ostrovsky; +Cc: david.vrabel, Jan Beulich, xen-devel

On Tue, Mar 22, Boris Ostrovsky wrote:

> Can you apply PAT changes from
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02127.html
> and see if it helps?
> 
> It should at least get rid of the splat (patch 3 is the one addresses
> no-MTRR problem that I mentioned above). We should still fix
> devmem_is_allowed() though.

Boris, using 02f037d^..b6350c2 fixes biosdevname in dom0 and reading
/dev/mem in a PV domU. Thanks.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2016-06-06 21:17 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-29 10:28 identify a Xen PV domU to fix devmem_is_allowed Olaf Hering
2016-02-29 15:10 ` Konrad Rzeszutek Wilk
2016-02-29 15:29   ` Olaf Hering
2016-02-29 18:32     ` Boris Ostrovsky
2016-03-01 15:14       ` Olaf Hering
2016-03-01 10:38   ` Jan Beulich
2016-03-01 14:34     ` Konrad Rzeszutek Wilk
2016-03-01 14:45       ` Boris Ostrovsky
2016-03-15 16:57         ` Olaf Hering
2016-03-15 18:56           ` Boris Ostrovsky
2016-03-21 21:29           ` Boris Ostrovsky
2016-03-22 18:37             ` Boris Ostrovsky
2016-03-23  8:28               ` Olaf Hering
2016-06-06 21:17               ` Olaf Hering
2016-03-01 16:23   ` Olaf Hering
2016-03-01 15:29 ` David Vrabel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).