> In the ACPI specification [1], the 'unarmed' bit is set when a device
> cannot accept a persistent write. This means that when a memdev is
> read-only, the 'unarmed' flag must be turned on. The logic is correct,
> just changing the error message.
>
> [1] ACPI NFIT NVDIMM Region Mapping Structure
On Tue, Oct 18, 2022 at 6:49 PM Michael S. Tsirkin wrote:
>
> On Tue, Oct 18, 2022 at 06:17:55PM +0200, Philippe Mathieu-Daudé wrote:
> > On 18/10/22 17:25, Julia Suvorova wrote:
> > > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > > cannot accept a persistent write. Thi
On 18.10.22 18:49, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2022 at 06:17:55PM +0200, Philippe Mathieu-Daudé wrote:
On 18/10/22 17:25, Julia Suvorova wrote:
In the ACPI specification [1], the 'unarmed' bit is set when a device
cannot accept a persistent write. This means that when a memdev is
On Tue, Oct 18, 2022 at 06:17:55PM +0200, Philippe Mathieu-Daudé wrote:
> On 18/10/22 17:25, Julia Suvorova wrote:
> > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > cannot accept a persistent write. This means that when a memdev is
> > read-only, the 'unarmed' flag must
On 18/10/22 17:25, Julia Suvorova wrote:
In the ACPI specification [1], the 'unarmed' bit is set when a device
cannot accept a persistent write. This means that when a memdev is
read-only, the 'unarmed' flag must be turned on. The logic is correct,
just changing the error message.
[1] ACPI NFIT
In the ACPI specification [1], the 'unarmed' bit is set when a device
cannot accept a persistent write. This means that when a memdev is
read-only, the 'unarmed' flag must be turned on. The logic is correct,
just changing the error message.
[1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM Sta
On Wed, Jun 15, 2022 at 7:49 PM David Hildenbrand wrote:
>
> On 15.06.22 13:17, Xiao Guangrong wrote:
> > On Wed, Jun 15, 2022 at 4:24 PM David Hildenbrand
wrote:
> >
> Is that a temporary or a permanent thing? Do we know?
> >>>
> >>> No idea. But his last signed-off was three years ago.
> >
On 15.06.22 13:17, Xiao Guangrong wrote:
> On Wed, Jun 15, 2022 at 4:24 PM David Hildenbrand wrote:
>
Is that a temporary or a permanent thing? Do we know?
>>>
>>> No idea. But his last signed-off was three years ago.
>>
>> I sent a patch to Xiao, asking if he's still active in QEMU. If I do
On Wed, Jun 15, 2022 at 4:24 PM David Hildenbrand wrote:
> >> Is that a temporary or a permanent thing? Do we know?
> >
> > No idea. But his last signed-off was three years ago.
>
> I sent a patch to Xiao, asking if he's still active in QEMU. If I don't
> get a reply this week, I'll move forward
On 14.06.22 14:13, Julia Suvorova wrote:
> On Tue, Jun 14, 2022 at 11:50 AM David Hildenbrand wrote:
>>
>> On 14.06.22 10:54, Igor Mammedov wrote:
>>> On Mon, 13 Jun 2022 16:09:53 +0100
>>> Stefan Hajnoczi wrote:
>>>
On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> On Tu
On Tue, 14 Jun 2022 11:50:43 +0200
David Hildenbrand wrote:
> On 14.06.22 10:54, Igor Mammedov wrote:
> > On Mon, 13 Jun 2022 16:09:53 +0100
> > Stefan Hajnoczi wrote:
> >
> >> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> >>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajno
On Tue, Jun 14, 2022 at 11:50 AM David Hildenbrand wrote:
>
> On 14.06.22 10:54, Igor Mammedov wrote:
> > On Mon, 13 Jun 2022 16:09:53 +0100
> > Stefan Hajnoczi wrote:
> >
> >> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> >>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi
On 14.06.22 10:54, Igor Mammedov wrote:
> On Mon, 13 Jun 2022 16:09:53 +0100
> Stefan Hajnoczi wrote:
>
>> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
>>> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi
>>> wrote:
On Tue, May 31, 2022 at 04:51:47PM +0200, Julia S
On Mon, 13 Jun 2022 16:09:53 +0100
Stefan Hajnoczi wrote:
> On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> > On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi
> > wrote:
> > >
> > > On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> > > > In the ACPI specific
On Mon, Jun 13, 2022 at 05:01:10PM +0200, Julia Suvorova wrote:
> On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi wrote:
> >
> > On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> > > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > > cannot accept a persist
On Tue, May 31, 2022 at 5:32 PM Stefan Hajnoczi wrote:
>
> On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> > In the ACPI specification [1], the 'unarmed' bit is set when a device
> > cannot accept a persistent write. This means that when a memdev is
> > read-only, the 'unarmed' f
On Tue, May 31, 2022 at 04:51:47PM +0200, Julia Suvorova wrote:
> In the ACPI specification [1], the 'unarmed' bit is set when a device
> cannot accept a persistent write. This means that when a memdev is
> read-only, the 'unarmed' flag must be turned on. The logic is correct,
> just changing the e
In the ACPI specification [1], the 'unarmed' bit is set when a device
cannot accept a persistent write. This means that when a memdev is
read-only, the 'unarmed' flag must be turned on. The logic is correct,
just changing the error message.
[1] ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM Sta
18 matches
Mail list logo
