Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-06-06 Thread Olaf Hering 
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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-23 Thread Olaf Hering 
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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-22 Thread Boris Ostrovsky 

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
001
[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
-0fff : reserved <
1000-0009 : System RAM
000a-000f : reserved   <=
  000f-000f : System ROM
0010-7fff : System RAM
  0100-0172a065 : Kernel code
  0172a066-01d32b3f : Kernel data
  01ec5000-02026fff : Kernel bss
fee0-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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-21 Thread Boris Ostrovsky 

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
001
[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
-0fff : reserved <
1000-0009 : System RAM
000a-000f : reserved   <=
  000f-000f : System ROM
0010-7fff : System RAM
  0100-0172a065 : Kernel code
  0172a066-01d32b3f : Kernel data
  01ec5000-02026fff : Kernel bss
fee0-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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-15 Thread Boris Ostrovsky 

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
001
[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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-15 Thread Olaf Hering 
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
> 001
> [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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-01 Thread Olaf Hering 
On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:

> .. A fix for what issue?

#include 
#include 
#include 
#include 
#include 

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: GW   
4.4.2-1-default #1
[ 1627.494958]  81a47bf1 88000240fc10 8137eb99 

[ 1627.495417]  88000240fc48 8107c552 88003f80a2e0 
0001
[ 1627.495881]  7f53e5e81000  7f53e5e81000 
88000240fc58
[ 1627.496365] Call Trace:
[ 1627.496834]  [] try_stack_unwind+0x175/0x190
[ 1627.497315]  [] dump_trace+0x69/0x3a0
[ 1627.497792]  [] show_trace_log_lvl+0x4b/0x60
[ 1627.498274]  [] show_stack_log_lvl+0x10c/0x180
[ 1627.498751]  [] show_stack+0x25/0x50
[ 1627.499225]  [] dump_stack+0x4b/0x72
[ 1627.499695]  [] warn_slowpath_common+0x82/0xc0
[ 1627.500179]  [] warn_slowpath_null+0x1a/0x20
[ 1627.500652]  [] xen_mc_flush+0x1c5/0x1d0
[ 1627.501126]  [] xen_leave_lazy_mmu+0x15/0x30
[ 1627.501599]  [] remap_pfn_range+0x34d/0x430
[ 1627.502078]  [] mmap_mem+0xcf/0x120
[ 1627.502552]  [] mmap_region+0x3f7/0x680
[ 1627.503025]  [] do_mmap+0x333/0x420
[ 1627.503495]  [] vm_mmap_pgoff+0x91/0xc0
[ 1627.503961]  [] SyS_mmap_pgoff+0x19f/0x260
[ 1627.504437]  [] SyS_mmap+0x1b/0x30
[ 1627.504899]  [] 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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-01 Thread David Vrabel 
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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-01 Thread Olaf Hering 
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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-01 Thread Boris Ostrovsky 

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,  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
001 00
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
001
[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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-01 Thread Konrad Rzeszutek Wilk 
On Tue, Mar 01, 2016 at 03:38:55AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 16:10,  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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-03-01 Thread Jan Beulich 
>>> On 29.02.16 at 16:10,  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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-02-29 Thread Boris Ostrovsky 

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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-02-29 Thread Olaf Hering 
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

Re: [Xen-devel] identify a Xen PV domU to fix devmem_is_allowed

2016-02-29 Thread Konrad Rzeszutek Wilk 
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