Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests
On Fri, Mar 17, 2017 at 04:03:59AM +0200, Michael S. Tsirkin wrote: > On Thu, Mar 16, 2017 at 05:14:15PM -0400, Gabriel L. Somlo wrote: > > On Thu, Mar 16, 2017 at 04:17:11PM -0400, Gabriel L. Somlo wrote: > > > On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wrote: > > > > On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote: > > > > > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote: > > > > > > Let's take a step back and try to figure out how is > > > > > > mwait called. How about dumping code of VCPUs > > > > > > around mwait? gdb disa command will do this. > > > > > > > > > > Started guest with '-s', tried to attach from gdb with > > > > > "target remote localhost:1234", got > > > > > "remote 'g' packet reply is too long: " > > > > > > > > Try > > > > > > > > set arch x86-64:x86-64 > > > > > > 'set architecture i386:x86-64:intel' is what worked for me; > > > > > > Been rooting around for a while, can't find mwait or monitor :( > > > > > > Guess I'll have to recompile KVM to actually issue an invalid opcode, > > > so OS X will print a panic message with the exact address :) > > > > > > Stay tuned... > > > > OK, so I found a few instances. The one closest to where a random > > interrupt from gdb landed, was this one: > > > > ... > >0xff7f813ff379: mov0x90(%r15),%rax > >0xff7f813ff380: mov0x18(%rax),%rsi > >0xff7f813ff384: xor%ecx,%ecx > >0xff7f813ff386: mov%rsi,%rax > >0xff7f813ff389: xor%edx,%edx > >0xff7f813ff38b: monitor %rax,%rcx,%rdx > >0xff7f813ff38e: test %r14,%r14 > >0xff7f813ff391: je 0xff7f813ff3ad > >0xff7f813ff393: movq $0x0,0x8(%r14) > >0xff7f813ff39b: movl $0x0,(%r14) > >0xff7f813ff3a2: test %ebx,%ebx > >0xff7f813ff3a4: je 0xff7f813ff3b2 > >0xff7f813ff3a6: mfence > >0xff7f813ff3a9: wbinvd > >0xff7f813ff3ab: jmp0xff7f813ff3b2 > >0xff7f813ff3ad: cmpl $0x0,(%rsi) > > Seems to do cmpl - could indicate it uses different bytes > for signalling? Radim's test monitors and > modifies the same byte... > > >0xff7f813ff3b0: jne0xff7f813ff3d6 > >0xff7f813ff3b2: mov%r12d,%eax > >0xff7f813ff3b5: imul $0x148,%rax,%rax > >0xff7f813ff3bc: lea0x153bd(%rip),%rcx# > > 0xff7f81414780 > >0xff7f813ff3c3: mov(%rcx),%rcx > >0xff7f813ff3c6: mov0x20(%rcx),%rcx > >0xff7f813ff3ca: mov0xc(%rcx,%rax,1),%eax > >0xff7f813ff3ce: mov$0x1,%ecx > >0xff7f813ff3d3: mwait %rax,%rcx > > => 0xff7f813ff3d6: lfence > >0xff7f813ff3d9: rdtsc > >0xff7f813ff3db: lfence > >0xff7f813ff3de: mov%rax,%rbx > >0xff7f813ff3e1: mov%rdx,%r15 > > ... > > OK nice, so it's actually using 1 for ECX. Now what's rax? > Can you check that with gdb pls, then try that value with > Radim's test? Thread 1 received signal SIGINT, Interrupt. 0xff80002c8991 in ?? () (gdb) break *0xff7f813ff3ce Breakpoint 1 at 0xff7f813ff3ce (gdb) continue Continuing. Thread 3 hit Breakpoint 1, 0xff7f813ff3ce in ?? () (gdb) p $rax $1 = 240 (gdb) cont Continuing. [Switching to Thread 1] Thread 1 hit Breakpoint 1, 0xff7f813ff3ce in ?? () (gdb) p $rax $2 = 240 (gdb) cont Continuing. [Switching to Thread 4] Thread 4 hit Breakpoint 1, 0xff7f813ff3ce in ?? () (gdb) p $rax $3 = 240 (gdb) cont Continuing. Thread 4 hit Breakpoint 1, 0xff7f813ff3ce in ?? () (gdb) p $rax $4 = 240 (gdb) So, 240 or 0xf0 OK, now on to Radim's test, on the MacPro1,1: [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 1' timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 1 enabling apic PASS: resumed from mwait 1 times SUMMARY: 1 tests real0m0.746s user0m0.542s sys 0m0.215s [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 0' timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 0 enabling apic PASS: resumed from mwait 1 times SUMMARY: 1 tests real0m0.743s user0m0.528s sys 0m0.226s [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 1' -smp 2 timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 1 -smp 2 enabling apic enabling apic FAIL: resumed from mwait 10150 times SUMMARY: 1 tests, 1 unexpected failures real0m0.745s user0m0.545s sys 0m0.214s [kvm-unit-tests]$ ti
Re: [PATCH v3 3/6] documentation: media: Add documentation for new RGB and YUV bus formats
On 03/16/2017 06:01 PM, Archit Taneja wrote: > > > On 3/7/2017 10:12 PM, Neil Armstrong wrote: >> Add documentation for added Bus Formats to describe RGB and YUS formats used > > s/YUS/YUV Thanks again > >> as input to the Synopsys DesignWare HDMI TX Controller. >> >> Signed-off-by: Neil Armstrong >> --- >> Documentation/media/uapi/v4l/subdev-formats.rst | 4992 >> ++- >> 1 file changed, 3963 insertions(+), 1029 deletions(-) > > Do we know if there is a better way to add more columns without > adding so many lines? It seems not, the reason is written in the commands. > If not, one option could be to create a separate tables for > 48 bit RGB formats, 48 bit YUV formats etc. It would be simple indeed, any V4L guys for an advice here ? Thanks, Neil > > > > Thanks, > Archit > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentaion: leds: leds-lp55xx.txt: Fix typos
Fix spelling mistakes in leds-lp55xx.txt file to make documentation clear. Signed-off-by: Tamara Diaconita --- Documentation/leds/leds-lp55xx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt index bcea12a..e23fa91 100644 --- a/Documentation/leds/leds-lp55xx.txt +++ b/Documentation/leds/leds-lp55xx.txt @@ -117,7 +117,7 @@ As soon as 'loading' is set to 0, registered callback is called. Inside the callback, the selected engine is loaded and memory is updated. To run programmed pattern, 'run_engine' attribute should be enabled. -The pattern sqeuence of LP8501 is similar to LP5523. +The pattern sequence of LP8501 is similar to LP5523. However pattern data is specific. Ex 1) Engine 1 is used echo 1 > /sys/bus/i2c/devices//select_engine -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: md: md-cluster.txt: Fix typos
Fix typos in md-cluster.txt file to make documentation clear. Signed-off-by: Tamara Diaconita --- Documentation/md/md-cluster.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/md/md-cluster.txt b/Documentation/md/md-cluster.txt index 3888327..35e05d4 100644 --- a/Documentation/md/md-cluster.txt +++ b/Documentation/md/md-cluster.txt @@ -77,7 +77,7 @@ There are three groups of locks for managing the device: 3.1.2 RESYNCING: informs other nodes that a resync is initiated or ended so that each node may suspend or resume the region. Each RESYNCING message identifies a range of the devices that the - sending node is about to resync. This over-rides any pervious + sending node is about to resync. This over-rides any previous notification from that node: only one ranged can be resynced at a time per-node. -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: md: md-cluster.txt: Fix typos
On 03/17/17 10:48, Tamara Diaconita wrote: > Fix typos in md-cluster.txt file to make documentation clear. > > Signed-off-by: Tamara Diaconita > --- > Documentation/md/md-cluster.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/md/md-cluster.txt b/Documentation/md/md-cluster.txt > index 3888327..35e05d4 100644 > --- a/Documentation/md/md-cluster.txt > +++ b/Documentation/md/md-cluster.txt > @@ -77,7 +77,7 @@ There are three groups of locks for managing the device: > 3.1.2 RESYNCING: informs other nodes that a resync is initiated or > ended so that each node may suspend or resume the region. Each > RESYNCING message identifies a range of the devices that the > - sending node is about to resync. This over-rides any pervious > + sending node is about to resync. This over-rides any previous Might as well fix this one also: overrides > notification from that node: only one ranged can be resynced at a > time per-node. > > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: mmc: mmc-dev-attrs.txt: Fix typos
Fix typos in mmc-dev-attrs.txt to make documentation clear. Signed-off-by: Tamara Diaconita --- Documentation/mmc/mmc-dev-attrs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index 404a0e9..2caff30 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -13,7 +13,7 @@ SD and MMC Device Attributes All attributes are read-only. - cid Card Identifaction Register + cid Card Identification Register csd Card Specific Data Register scr SD Card Configuration Register (SD only) dateManufacturing Date (from CID Register) @@ -71,6 +71,6 @@ Note on Erase Size and Preferred Erase Size: "preferred_erase_size" is in bytes. Note on raw_rpmb_size_mult: - "raw_rpmb_size_mult" is a mutliple of 128kB block. + "raw_rpmb_size_mult" is a multiple of 128kB block. RPMB size in byte is calculated by using the following equation: RPMB partition size = 128kB x raw_rpmb_size_mult -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation: md: md-cluster.txt: Fix typos
Fix typos in md-cluster.txt file to make documentation clear. Signed-off-by: Tamara Diaconita --- Changes since v1: *Correct 'over-rides' to 'overrides'. Documentation/md/md-cluster.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/md/md-cluster.txt b/Documentation/md/md-cluster.txt index 3888327..d221039 100644 --- a/Documentation/md/md-cluster.txt +++ b/Documentation/md/md-cluster.txt @@ -77,7 +77,7 @@ There are three groups of locks for managing the device: 3.1.2 RESYNCING: informs other nodes that a resync is initiated or ended so that each node may suspend or resume the region. Each RESYNCING message identifies a range of the devices that the - sending node is about to resync. This over-rides any pervious + sending node is about to resync. This overrides any previous notification from that node: only one ranged can be resynced at a time per-node. -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] lib/Kconfig.debug: correct documentation paths
On Thu, 16 Mar 2017 09:37:32 +0100 Hans Holmberg wrote: > A bunch of documentation files have moved, correct the paths. Applied (finally!) to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: sync_file.txt: Fix typos
On Thu, 16 Mar 2017 17:39:46 +0200 Tamara Diaconita wrote: > Fix spelling mistakes in sync_file.txt to make documentation clear. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: vfio-mediated-device.txt: Fix typos
On Thu, 16 Mar 2017 17:42:16 +0200 Tamara Diaconita wrote: > Correct spelling mistakes in vfio-mediates-device.txt to make > documentation clear. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentaion: leds: leds-lp55xx.txt: Fix typos
On Fri, 17 Mar 2017 19:29:48 +0200 Tamara Diaconita wrote: > Fix spelling mistakes in leds-lp55xx.txt file to make documentation > clear. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: mmc: mmc-dev-attrs.txt: Fix typos
On Fri, 17 Mar 2017 20:00:34 +0200 Tamara Diaconita wrote: > Fix typos in mmc-dev-attrs.txt to make documentation clear. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: md: md-cluster.txt: Fix typos
On Fri, 17 Mar 2017 20:14:08 +0200 Tamara Diaconita wrote: > Fix typos in md-cluster.txt file to make documentation clear. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v4 24/28] x86: Access the setup data through debugfs decrypted
On 3/8/2017 1:04 AM, Dave Young wrote:
On 02/16/17 at 09:47am, Tom Lendacky wrote:
Use memremap() to map the setup data. This simplifies the code and will
make the appropriate decision as to whether a RAM remapping can be done
or if a fallback to ioremap_cache() is needed (which includes checking
PageHighMem).
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/kdebugfs.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index bdb83e4..c3d354d 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -48,17 +48,13 @@ static ssize_t setup_data_read(struct file *file, char
__user *user_buf,
pa = node->paddr + sizeof(struct setup_data) + pos;
pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- p = ioremap_cache(pa, count);
- if (!p)
- return -ENXIO;
- } else
- p = __va(pa);
+ p = memremap(pa, count, MEMREMAP_WB);
+ if (!p)
+ return -ENXIO;
-ENOMEM looks better for memremap, ditto for other places..
Makes sense, I'll change them.
Thanks,
Tom
remain = copy_to_user(user_buf, p, count);
- if (PageHighMem(pg))
- iounmap(p);
+ memunmap(p);
if (remain)
return -EFAULT;
@@ -127,15 +123,12 @@ static int __init create_setup_data_nodes(struct dentry
*parent)
}
pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
- if (PageHighMem(pg)) {
- data = ioremap_cache(pa_data, sizeof(*data));
- if (!data) {
- kfree(node);
- error = -ENXIO;
- goto err_dir;
- }
- } else
- data = __va(pa_data);
+ data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
+ if (!data) {
+ kfree(node);
+ error = -ENXIO;
+ goto err_dir;
+ }
node->paddr = pa_data;
node->type = data->type;
@@ -143,8 +136,7 @@ static int __init create_setup_data_nodes(struct dentry
*parent)
error = create_setup_data_node(d, no, node);
pa_data = data->next;
- if (PageHighMem(pg))
- iounmap(data);
+ memunmap(data);
if (error)
goto err_dir;
no++;
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: acpi: Fix typos
On Wed, 15 Mar 2017 01:05:43 +0200 Tamara Diaconita wrote: > Fix typos in acpi directory to make documentation grammatically correct. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear
On 3/8/2017 12:55 AM, Dave Young wrote:
On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
+ * This function determines if an address should be mapped encrypted.
+ * Boot setup data, EFI data and E820 areas are checked in making this
+ * determination.
+ */
+static bool memremap_should_map_encrypted(resource_size_t phys_addr,
+ unsigned long size)
+{
+ /*
+* SME is not active, return true:
+* - For early_memremap_pgprot_adjust(), returning true or false
+* results in the same protection value
+* - For arch_memremap_do_ram_remap(), returning true will allow
+* the RAM remap to occur instead of falling back to ioremap()
+*/
+ if (!sme_active())
+ return true;
From the function name shouldn't above be return false?
I've re-worked this so that the check is in a different location and
doesn't cause confusion.
+
+ /* Check if the address is part of the setup data */
+ if (memremap_is_setup_data(phys_addr, size))
+ return false;
+
+ /* Check if the address is part of EFI boot/runtime data */
+ switch (efi_mem_type(phys_addr)) {
+ case EFI_BOOT_SERVICES_DATA:
+ case EFI_RUNTIME_SERVICES_DATA:
Only these two types needed? I'm not sure about this, just bring up the
question.
I've re-worked this code so that there is a single EFI routine that
checks boot_params.efi_info.efi_memmap/efi_systab, EFI tables and the
EFI memtype. As for the EFI memtypes, I believe those are the only
ones required. Some of the other types will be picked up by the e820
checks (ACPI, NVS, etc.).
Thanks,
Tom
+ return false;
+ default:
+ break;
+ }
+
+ /* Check if the address is outside kernel usable area */
+ switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
+ case E820_TYPE_RESERVED:
+ case E820_TYPE_ACPI:
+ case E820_TYPE_NVS:
+ case E820_TYPE_UNUSABLE:
+ return false;
+ default:
+ break;
+ }
+
+ return true;
+}
+
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v4 25/28] x86: Access the setup data through sysfs decrypted
On 3/8/2017 1:09 AM, Dave Young wrote:
On 02/16/17 at 09:47am, Tom Lendacky wrote:
Use memremap() to map the setup data. This will make the appropriate
decision as to whether a RAM remapping can be done or if a fallback to
ioremap_cache() is needed (similar to the setup data debugfs support).
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/ksysfs.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
index 4afc67f..d653b3e 100644
--- a/arch/x86/kernel/ksysfs.c
+++ b/arch/x86/kernel/ksysfs.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -79,12 +80,12 @@ static int get_setup_data_paddr(int nr, u64 *paddr)
*paddr = pa_data;
return 0;
}
- data = ioremap_cache(pa_data, sizeof(*data));
+ data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
if (!data)
return -ENOMEM;
pa_data = data->next;
- iounmap(data);
+ memunmap(data);
i++;
}
return -EINVAL;
@@ -97,17 +98,17 @@ static int __init get_setup_data_size(int nr, size_t *size)
u64 pa_data = boot_params.hdr.setup_data;
while (pa_data) {
- data = ioremap_cache(pa_data, sizeof(*data));
+ data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
if (!data)
return -ENOMEM;
if (nr == i) {
*size = data->len;
- iounmap(data);
+ memunmap(data);
return 0;
}
pa_data = data->next;
- iounmap(data);
+ memunmap(data);
i++;
}
return -EINVAL;
@@ -127,12 +128,12 @@ static ssize_t type_show(struct kobject *kobj,
ret = get_setup_data_paddr(nr, &paddr);
if (ret)
return ret;
- data = ioremap_cache(paddr, sizeof(*data));
+ data = memremap(paddr, sizeof(*data), MEMREMAP_WB);
if (!data)
return -ENOMEM;
ret = sprintf(buf, "0x%x\n", data->type);
- iounmap(data);
+ memunmap(data);
return ret;
}
@@ -154,7 +155,7 @@ static ssize_t setup_data_data_read(struct file *fp,
ret = get_setup_data_paddr(nr, &paddr);
if (ret)
return ret;
- data = ioremap_cache(paddr, sizeof(*data));
+ data = memremap(paddr, sizeof(*data), MEMREMAP_WB);
if (!data)
return -ENOMEM;
@@ -170,15 +171,15 @@ static ssize_t setup_data_data_read(struct file *fp,
goto out;
ret = count;
- p = ioremap_cache(paddr + sizeof(*data), data->len);
+ p = memremap(paddr + sizeof(*data), data->len, MEMREMAP_WB);
if (!p) {
ret = -ENOMEM;
goto out;
}
memcpy(buf, p + off, count);
- iounmap(p);
+ memunmap(p);
out:
- iounmap(data);
+ memunmap(data);
return ret;
}
@@ -250,13 +251,13 @@ static int __init get_setup_data_total_num(u64 pa_data,
int *nr)
*nr = 0;
while (pa_data) {
*nr += 1;
- data = ioremap_cache(pa_data, sizeof(*data));
+ data = memremap(pa_data, sizeof(*data), MEMREMAP_WB);
if (!data) {
ret = -ENOMEM;
goto out;
}
pa_data = data->next;
- iounmap(data);
+ memunmap(data);
}
out:
It would be better that these cleanup patches are sent separately.
Bjorn suggested something along the same line so I've combined all the
changes from ioremap to memremap as a single pre-patch in the series.
I could send them separately if needed.
Thanks,
Tom
Acked-by: Dave Young
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH v4 15/28] Add support to access persistent memory in the clear
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tom Lendacky
> Sent: Thursday, February 16, 2017 9:45 AM
> Subject: [RFC PATCH v4 15/28] Add support to access persistent memory in
> the clear
>
> Persistent memory is expected to persist across reboots. The encryption
> key used by SME will change across reboots which will result in corrupted
> persistent memory. Persistent memory is handed out by block devices
> through memory remapping functions, so be sure not to map this memory as
> encrypted.
The system might be able to save and restore the correct encryption key for a
region of persistent memory, in which case it does need to be mapped as
encrypted.
This might deserve a new EFI_MEMORY_ENCRYPTED attribute bit so the
system firmware can communicate that information to the OS (in the
UEFI memory map and the ACPI NFIT SPA Range structures). It wouldn't
likely ever be added to the E820h table - ACPI 6.1 already obsoleted the
Extended Attribute for AddressRangeNonVolatile.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/mm/ioremap.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index b0ff6bc..c6cb921 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -498,6 +498,8 @@ static bool
> memremap_should_map_encrypted(resource_size_t phys_addr,
> case E820_TYPE_ACPI:
> case E820_TYPE_NVS:
> case E820_TYPE_UNUSABLE:
> + case E820_TYPE_PMEM:
> + case E820_TYPE_PRAM:
> return false;
> default:
> break;
E820_TYPE_RESERVED is also used to report persistent memory in
some systems (patch 16 adds that for other reasons).
You might want to intercept the persistent memory types in the
efi_mem_type(phys_addr) switch statement earlier in the function
as well. https://lkml.org/lkml/2017/3/13/357 recently mentioned that
"in qemu hotpluggable memory isn't put into E820," with the latest
information only in the UEFI memory map.
Persistent memory can be reported there as:
* EfiReservedMemoryType type with the EFI_MEMORY_NV attribute
* EfiPersistentMemory type with the EFI_MEMORY_NV attribute
Even the UEFI memory map is not authoritative, though. To really
determine what is in these regions requires parsing the ACPI NFIT
SPA Ranges structures. Parts of the E820 or UEFI regions could be
reported as volatile there and should thus be encrypted.
---
Robert Elliott, HPE Persistent Memory
N�r��yb�X��ǧv�^�){.n�+{�v�"��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
