So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 124
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
Reviewed-by: Maxim Levitsky
---
hw/block/nvme.c | 1 +
include
Resending series recently posted on mailing list related to nvme device
extension with couple of fixes after review.
This patch series does following:
- Fixes problem where CMBS bit was not set in controller capabilities
register, so support for CMB was not correctly advertised to guest.
Th
On 7/29/20 2:24 PM, Klaus Jensen wrote:
> On Jul 29 13:40, Andrzej Jakowski wrote:
>> On 7/20/20 4:37 AM, Klaus Jensen wrote:
>>> From: Klaus Jensen
>>>
>>> Add nvme_map_addr, nvme_map_addr_cmb and nvme_addr_to_cmb helpers and
>>> use them in nvme_m
ov, (void *)&n->cmbuf[prp2 -
> n->ctrl_mem.addr], trans_len);
> +status = nvme_map_addr(n, qsg, iov, prp2, len);
> +if (status) {
> +goto unmap;
> }
> }
> }
> return NVME_SUCCESS;
>
>
On 7/27/20 2:06 AM, Klaus Jensen wrote:
> On Jul 23 09:03, Andrzej Jakowski wrote:
>> So far it was not possible to have CMB and PMR emulated on the same
>> device, because BAR2 was used exclusively either of PMR or CMB. This
>> patch places CMB at BAR4 offset so it not
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
Reviewed-by: Maxim Levitsky
---
hw/block/nvme.c | 1 +
include
So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 120
Resending series recently posted on mailing list related to nvme device
extension with couple of fixes after review.
This patch series does following:
- Exports memory_region_to_absolute_addr() function so it is avaialbe
for use by drivers. This function is needed by 3rd patch in this
serie
This change exports memory_region_to_absolute_addr() function so it can
be used by drivers requiring to calculate absolute address for memory
subregions when memory hierarchy is used.
Signed-off-by: Andrzej Jakowski
---
include/exec/memory.h | 9 +
softmmu/memory.c | 2 +-
2 files
On 7/22/20 10:21 AM, Klaus Jensen wrote:
> On Jul 22 10:00, Andrzej Jakowski wrote:
>> On 7/22/20 12:43 AM, Klaus Jensen wrote:
>>> @keith, please see below - can you comment on the Linux kernel 2 MB
>>> boundary requirement for the CMB? Or should we hail Stephen (or
On 7/22/20 12:43 AM, Klaus Jensen wrote:
> @keith, please see below - can you comment on the Linux kernel 2 MB
> boundary requirement for the CMB? Or should we hail Stephen (or Logan
> maybe) since this seems to be related to p2pdma?
>
> On Jul 21 14:54, Andrzej Jakowski wrote:
>
On 7/15/20 1:06 AM, Klaus Jensen wrote:
> Hi Andrzej,
>
> I've not been ignoring this, but sorry for not following up earlier.
>
> I'm hesitent to merge anything that very obviously breaks an OS that we
> know is used a lot to this using this device. Also because the issue has
> not been analyzed
On 7/6/20 12:15 AM, Klaus Jensen wrote:
> On Jul 2 16:33, Andrzej Jakowski wrote:
>> On 7/2/20 10:51 AM, Klaus Jensen wrote:
>>> On Jul 2 08:07, Andrzej Jakowski wrote:
>>>> On 7/2/20 3:31 AM, Klaus Jensen wrote:
>>>>> Aight, an update here. This
On 7/2/20 10:51 AM, Klaus Jensen wrote:
> On Jul 2 08:07, Andrzej Jakowski wrote:
>> On 7/2/20 3:31 AM, Klaus Jensen wrote:
>>> Aight, an update here. This only happens when QEMU is run with a virtual
>>> IOMMU. Otherwise, the kernel is happy.
>>>
>>&g
w in the
>>> near future and how much control he wants to keep over the development,
>>> I could imagine adding Klaus to MAINTAINERS, either as a co-maintainer
>>> or as a reviewer. Then I could rely on reviews/acks from either of you
>>> for merging series.
>>
On 7/2/20 3:31 AM, Klaus Jensen wrote:
> Aight, an update here. This only happens when QEMU is run with a virtual
> IOMMU. Otherwise, the kernel is happy.
>
> With the vIOMMU, qemu also craps out a bit:
>
> qemu-system-x86_64: vtd_iova_to_slpte: detected slpte permission error
> (iova=0xfd20
On 6/30/20 9:45 AM, Klaus Jensen wrote:
> On Jun 30 17:16, Philippe Mathieu-Daudé wrote:
>> On 6/30/20 5:10 PM, Andrzej Jakowski wrote:
>>> On 6/30/20 4:04 AM, Philippe Mathieu-Daudé wrote:
>>>> The Persistent Memory Region Controller Memory Space Control
>>>
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
---
hw/block/nvme.c | 2 +-
include/block/nvme.h | 6 +-
2 files
So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 101
Hi All,
Resending series recently posted on mailing list related to nvme device
extension with couple of fixes after review.
This patch series does following:
- Fixes problem where CMBS bit was not set in controller capabilities
register, so support for CMB was not correctly advertised to gu
introduce PMR support from NVMe 1.4 spec")
> Reported-by: Klaus Jensen
> Reviewed-by: Klaus Jensen
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Cc: Andrzej Jakowski
> ---
> include/block/nvme.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On 6/25/20 4:13 AM, Klaus Jensen wrote:
> On Jun 22 11:25, Andrzej Jakowski wrote:
>> So far it was not possible to have CMB and PMR emulated on the same
>> device, because BAR2 was used exclusively either of PMR or CMB. This
>> patch places CMB at BAR4 offset so it not
Hi All,
Resending series recently posted on mailing list related to nvme device
extension with couple of fixes after review.
This patch series does following:
- Fixes problem where CMBS bit was not set in controller capabilities
register, so support for CMB was not correctly advertised to g
So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 119
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
---
hw/block/nvme.c | 2 +-
include/block/nvme.h | 6 +-
2 files
On 6/18/20 2:25 AM, Klaus Jensen wrote:
> On Jun 16 22:18, Andrzej Jakowski wrote:
>> So far it was not possible to have CMB and PMR emulated on the same
>> device, because BAR2 was used exclusively either of PMR or CMB. This
>> patch places CMB at BAR4 offset so it not
Hi All,
Resending series recently posted on mailing list related to nvme device
extension.
This patch series does following:
- Fixes problem where CMBS bit was not set in controller capabilities
register, so support for CMB was not correctly advertised to guest.
This is resend of patch t
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
---
hw/block/nvme.c | 2 +-
include/block/nvme.h | 6 +-
2 files
So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 122
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
---
hw/block/nvme.c | 2 +-
include/block/nvme.h | 6 +-
2 files
This patch series does following:
- Fixes problem where CMBS bit was not set in controller capabilities
register, so support for CMB was not correctly advertised to guest.
This is resend of patch that has been submitted and reviewed by
Klaus [1]
- Introduces BAR4 sharing between MSI-X ve
So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 120
On 6/8/20 1:08 AM, Klaus Jensen wrote:
> On Jun 5 11:10, Andrzej Jakowski wrote:
>> So far it was not possible to have CMB and PMR emulated on the same
>> device, because BAR2 was used exclusively either of PMR or CMB. This
>> patch places CMB at BAR4 offset so it not conflic
This patch series does following:
- Fixes problem where CMBS bit was not set in controller capabilities
register, so support for CMB was not correctly advertised to guest.
This is resend of patch that has been submitted and reviewed by
Klaus [1]
- Introduces BAR4 sharing between MSI-X ve
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly
reported to guest OS.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
---
hw/block/nvme.c | 2 ++
include/block/nvme.h | 6 +-
2 files
So far it was not possible to have CMB and PMR emulated on the same
device, because BAR2 was used exclusively either of PMR or CMB. This
patch places CMB at BAR4 offset so it not conflicts with MSI-X vectors.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 127
This patch sets CMBS bit in controller capabilities register when user
configures NVMe driver with CMB support, so capabilites are correctly reported
to guest OS.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 2 ++
include/block/nvme.h | 4
2 files changed, 6 insertions
On 3/30/20 12:31 PM, Klaus Birkelund Jensen wrote:
> On Mar 31 03:13, Keith Busch wrote:
>> On Mon, Mar 30, 2020 at 08:07:32PM +0200, Klaus Birkelund Jensen wrote:
>>> On Mar 31 01:55, Keith Busch wrote:
>>>> On Mon, Mar 30, 2020 at 09:46:56AM -0700, Andrzej Ja
the PMR region that will
stay
persistent across system reboot.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
Reviewed-by: Stefan Hajnoczi
---
Changelog:
v4:
- replaced qemu_msync() use with qemu_ram_writeback() to allow pmem_persist()
or qemu_msync() be called depending on
On 3/23/20 6:28 AM, Stefan Hajnoczi wrote:
> Excellent, thank you!
>
> Reviewed-by: Stefan Hajnoczi
Awesome, thx! Not sure about process...
Is this patch now staged for inclusion in QEMU?
the PMR region that will
stay
persistent across system reboot.
Signed-off-by: Andrzej Jakowski
Reviewed-by: Klaus Jensen
---
v3:
- replaced qemu_msync() use with qemu_ram_writeback() to allow pmem_persist()
or qemu_msync() be called depending on configuration [4] (Stefan)
- rephrased
On 3/20/20 8:45 AM, Stefan Hajnoczi wrote:
> Please use qemu_ram_writeback() so that pmem_persist() and qemu_msync()
> are used as appropriate.
Thx!
qemu_ram_writeback() doesn't return any status. How can I know that actual
msync succeds?
Also qemu_ram_writeback() requires me to include #include
the PMR region that will
stay
persistent across system reboot.
Signed-off-by: Andrzej Jakowski
---
v2:
- reworked PMR to use HostMemoryBackend instead of directly mapping PMR
backend file into qemu [1] (Stefan)
v1:
- provided support for Bit 1 from PMRWBM register instead of Bit 0 to ensure
On 3/17/20 4:23 AM, Stefan Hajnoczi wrote:
>> Code is posted here
>> https://github.com/AndrzejJakowski/qemu/commit/3a7762a1d13ff1543d1da430748eb24e38faab6f
>>
>> QEMU command line:
>>
>> # below are just relevant pieces of configuration, other stuff omitted
>> # tried different setting (e.g. pmem=
On 3/16/20 4:32 AM, Stefan Hajnoczi wrote:
> On Wed, Mar 11, 2020 at 11:08:27PM -0700, Klaus Birkelund Jensen wrote:
>> On Mar 11 15:54, Andrzej Jakowski wrote:
>>> On 3/11/20 2:20 AM, Stefan Hajnoczi wrote:
>>>> Please try:
>>>>
>>>> $
On 3/11/20 2:20 AM, Stefan Hajnoczi wrote:
> Please try:
>
> $ git grep pmem
>
> backends/hostmem-file.c is the backend that can be used and the
> pmem_persist() API can be used to flush writes.
I've reworked this patch into hostmem-file type of backend.
>From simple tests in virtual machine:
On 3/11/20 2:20 AM, Stefan Hajnoczi wrote:
> Oh, I think I see what you mean. That is not how the term
> "preallocated" is usually used in POSIX file systems. File systems
> have sparse files by default and the term preallocation is used in the
> context of fadvise(2) for reserving space.
>
> In
On 3/10/20 2:51 AM, Stefan Hajnoczi wrote:
> On Fri, Mar 06, 2020 at 03:38:53PM -0700, Andrzej Jakowski wrote:
>> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
>> index d28335cbf3..ff7e74d765 100644
>> --- a/hw/block/nvme.c
>> +++ b/hw/block/nvme.c
>> @@ -19,10
ystem reboot.
Signed-off-by: Andrzej Jakowski
---
Changes since v1:
- provided support for Bit 1 from PMRWBM register instead of Bit 0 to ensure
improved performance in virtualized environment [1] (Stefan)
- added check if pmr size is power of two in size (David)
- addressed cross compil
On 2/21/20 2:23 PM, Andrzej Jakowski wrote:
> This patch introduces support for PMR that has been defined as part of NVMe
> 1.4
> spec. User can now specify a pmr_file which will be mmap'ed into qemu address
> space and subsequently in PCI BAR 2. Guest OS can perform mmio read an
On 2/21/20 2:23 PM, Andrzej Jakowski wrote:
> This patch introduces support for PMR that has been defined as part of NVMe
> 1.4
> spec. User can now specify a pmr_file which will be mmap'ed into qemu address
> space and subsequently in PCI BAR 2. Guest OS can perform mmio read an
ystem reboot.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 165 +++-
hw/block/nvme.h | 5 ++
hw/block/trace-events | 5 ++
include/block/nvme.h | 172 ++
4 files changed, 346 insertions(+), 1 del
implements initial support for it in NVMe driver.
Andrzej Jakowski (1):
block/nvme: introduce PMR support from NVMe 1.4 spec
hw/block/nvme.c | 165 +++-
hw/block/nvme.h | 5 ++
hw/block/trace-events | 5 ++
include/block/nvme.h | 172
On 2/21/20 12:32 PM, Stefan Hajnoczi wrote:
> Hi Andrzej,
> After having looked at the PMRWBM part of the spec, I think that the
> Bit 1 mode should be implemented for slightly better performance. Bit
> 0 mode is not well-suited to virtualization for the reasons I
> mentioned in the previous email
On 2/21/20 11:45 AM, Dr. David Alan Gilbert wrote:
> Isn't there also a requirement that BARs are powers of two? Wouldn't
> you need to ensure the PMR file is a power of 2 in size?
>
> Dave
Agree, need to make sure it is power of 2.
On 2/21/20 6:45 AM, Stefan Hajnoczi wrote:
> Why is msync(2) done on memory loads instead of stores?
This is my interpretation of NVMe spec wording with regards to PMRWBM field
which says:
"The completion of a memory read from any Persistent
Memory Region address ensures that all prior writes to
On 2/18/20 6:07 PM, no-re...@patchew.org wrote:
> === TEST SCRIPT BEGIN ===
> #! /bin/bash
> export ARCH=x86_64
> make docker-image-fedora V=1 NETWORK=1
> time make docker-test-mingw@fedora J=14 NETWORK=1
> === TEST SCRIPT END ===
>
> CC hw/display/sii9022.o
> CC hw/display/ssd0303.o
ystem reboot.
Signed-off-by: Andrzej Jakowski
---
hw/block/nvme.c | 145 ++-
hw/block/nvme.h | 5 ++
hw/block/trace-events | 5 ++
include/block/nvme.h | 172 ++
4 files changed, 326 insertions(+), 1 del
59 matches
Mail list logo
