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
12 matches
Mail list logo
