On Tue, May 4, 2021 at 2:03 AM Aneesh Kumar K.V
wrote:
>
> On 5/4/21 11:13 AM, Pankaj Gupta wrote:
>
>
> >>
> >> What this patch series did was to express that property via a device
> >> tree node and guest driver enables a hypercall based flush mechanism to
> >> ensure persistence.
> >
> > W
On 5/4/21 11:13 AM, Pankaj Gupta wrote:
What this patch series did was to express that property via a device
tree node and guest driver enables a hypercall based flush mechanism to
ensure persistence.
Would VIRTIO (entirely asynchronous, no trap at host side) based
mechanism is better
th
> > The proposal that "sync-dax=unsafe" for non-PPC architectures, is a
> > fundamental misrepresentation of how this is supposed to work. Rather
> > than make "sync-dax" a first class citizen of the device-description
> > interface I'm proposing that you make this a separate device-type.
> > This
On 5/4/21 1:11 AM, Dan Williams wrote:
On Mon, May 3, 2021 at 7:06 AM Shivaprasad G Bhat wrote:
.
The proposal that "sync-dax=unsafe" for non-PPC architectures, is a
fundamental misrepresentation of how this is supposed to work. Rather
than make "sync-dax" a first class citizen of th
On Mon, May 3, 2021 at 7:06 AM Shivaprasad G Bhat wrote:
>
>
> On 5/1/21 12:44 AM, Dan Williams wrote:
> > Some corrections to terminology confusion below...
> >
> >
> > On Wed, Apr 28, 2021 at 8:49 PM Shivaprasad G Bhat
> > wrote:
> >> The nvdimm devices are expected to ensure write persistence
On 5/1/21 12:44 AM, Dan Williams wrote:
Some corrections to terminology confusion below...
On Wed, Apr 28, 2021 at 8:49 PM Shivaprasad G Bhat wrote:
The nvdimm devices are expected to ensure write persistence during power
failure kind of scenarios.
No, QEMU is not expected to make that gua
On 5/1/21 12:44 AM, Dan Williams wrote:
Some corrections to terminology confusion below...
...
file on the host in case of file backed v-nvdimms. This is addressed by
virtio-pmem in case of x86_64 by making explicit flushes translating to
fsync at qemu.
Note that virtio-pmem was a pro
Some corrections to terminology confusion below...
On Wed, Apr 28, 2021 at 8:49 PM Shivaprasad G Bhat wrote:
>
> The nvdimm devices are expected to ensure write persistence during power
> failure kind of scenarios.
No, QEMU is not expected to make that guarantee. QEMU is free to lie
to the gues
On Fri, Apr 30, 2021 at 02:27:18PM +1000, David Gibson wrote:
> On Thu, Apr 29, 2021 at 10:02:23PM +0530, Aneesh Kumar K.V wrote:
> > On 4/29/21 9:25 PM, Stefan Hajnoczi wrote:
> > > On Wed, Apr 28, 2021 at 11:48:21PM -0400, Shivaprasad G Bhat wrote:
> > > > The nvdimm devices are expected to ensur
On Thu, Apr 29, 2021 at 10:02:23PM +0530, Aneesh Kumar K.V wrote:
> On 4/29/21 9:25 PM, Stefan Hajnoczi wrote:
> > On Wed, Apr 28, 2021 at 11:48:21PM -0400, Shivaprasad G Bhat wrote:
> > > The nvdimm devices are expected to ensure write persistence during power
> > > failure kind of scenarios.
> >
On 4/29/21 9:25 PM, Stefan Hajnoczi wrote:
On Wed, Apr 28, 2021 at 11:48:21PM -0400, Shivaprasad G Bhat wrote:
The nvdimm devices are expected to ensure write persistence during power
failure kind of scenarios.
The libpmem has architecture specific instructions like dcbf on POWER
to flush the c
On Wed, Apr 28, 2021 at 11:48:21PM -0400, Shivaprasad G Bhat wrote:
> The nvdimm devices are expected to ensure write persistence during power
> failure kind of scenarios.
>
> The libpmem has architecture specific instructions like dcbf on POWER
> to flush the cache data to backend nvdimm device d
The nvdimm devices are expected to ensure write persistence during power
failure kind of scenarios.
The libpmem has architecture specific instructions like dcbf on POWER
to flush the cache data to backend nvdimm device during normal writes
followed by explicit flushes if the backend devices are no
13 matches
Mail list logo
