qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eric DeVolder <eric.devolder@oracle.com>
Cc: "ehabkost@redhat.com" <ehabkost@redhat.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"jusual@redhat.com" <jusual@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [PATCH v2 3/7] ACPI ERST: support for ACPI ERST feature
Date: Thu, 20 May 2021 13:00:47 +0200	[thread overview]
Message-ID: <20210520130047.1a89d520@redhat.com> (raw)
In-Reply-To: <CO1PR10MB4531D0D81AEDA7FD7F10DF19972C9@CO1PR10MB4531.namprd10.prod.outlook.com>

On Tue, 18 May 2021 17:08:31 +0000
Eric DeVolder <eric.devolder@oracle.com> wrote:

> Hi Igor,
> Thanks for the information. I am primarily interested in ensuring data persistence in the case of #1.
> As it stands so far, I have yet to observe any kind of write back into the backing file. Just to summarize,
> what I've done thus far is:
> 
> in erst_realizefn():
> ...
>     s->hostmem_obj = object_new(TYPE_MEMORY_BACKEND_FILE);
>     object_property_set_str(s->hostmem_obj, "mem-path", (const char *)(TYPE_ACPI_ERST ".hostmem"), &error_fatal);
>     object_property_set_int(s->hostmem_obj, "size", s->prop_size, &error_fatal);
>     user_creatable_complete(USER_CREATABLE(s->hostmem_obj), &error_fatal);
>     s->hostmem = MEMORY_BACKEND(s->hostmem_obj);

backend should be provided by user on CLI so all backend's properties are configured there
as user desires and frontend should access it via link property.
see how pc-dimm's memdev property is used.

> and then in erst_update_backing_file(), which is called when records are created/updated:
> 
> ...
>     if ((mr = host_memory_backend_get_memory(s->hostmem))) {
>         uint8_t *p = (uint8_t *)memory_region_get_ram_ptr(mr);
>         memcpy(p + offset, data, length);
>         memory_region_msync(mr, 0, s->prop_size); /* for now, the whole thing */
> }
> 
> I've instrumented this code, and I can see the records. I've instrumented memory_region_msync() all the way down
> to qemu_msync() and it makes it into that code. But the end result has always been the same, the backing file is
> never updated.
> 
> I'm not really sure what else I need to do to get the hostmem contents to be written back into the file.

see "man mmap"
 in particular MAP_SHARED vs MAP_PRIVATE

and there is a corresponding property for the file backend to manage that.

in case #1 no explicit sync is needed, backing file should be updated on close at the latest
(whether it's graceful/or forced (i.e. crash))


> Thanks,
> eric
> 
> 
> ________________________________
> From: Igor Mammedov <imammedo@redhat.com>
> Sent: Monday, May 17, 2021 11:31 AM
> To: Eric DeVolder <eric.devolder@oracle.com>
> Cc: ehabkost@redhat.com <ehabkost@redhat.com>; mst@redhat.com <mst@redhat.com>; Konrad Wilk <konrad.wilk@oracle.com>; qemu-devel@nongnu.org <qemu-devel@nongnu.org>; pbonzini@redhat.com <pbonzini@redhat.com>; Boris Ostrovsky <boris.ostrovsky@oracle.com>; rth@twiddle.net <rth@twiddle.net>; jusual@redhat.com <jusual@redhat.com>
> Subject: Re: [PATCH v2 3/7] ACPI ERST: support for ACPI ERST feature
> 
> On Mon, 17 May 2021 15:01:02 +0000
> Eric DeVolder <eric.devolder@oracle.com> wrote:
> 
> > Hi Igor,
> > I've been working to transition ERST to use the hostmem-file object as the backing store, as requested.
> >
> > I have the backend-file object now in ERST, and I have a question for you. This hostmem-file initializes
> > itself from a file, but in looking at the code, I do not see that it ever writes back to the file!? Furthermore,
> > I don't see a "flush" type method to force writeback of data in the object back to file?
> >
> > The original ERST code would flush/write to the backing file each record as it was created. I don't see
> > any equivalent way of doing that with hostmem-file?  
> 
> To force flush you can use memory_region_msync() on MemoryRegion that you get from hostmem backend.
> But question is what are you trying to achieve with sync
>   1. data persistence in case of QEMU crash
>   2. data persistence in case of host crash
> 
> for the former you do not need explicit sync as memory buffers should be flushed to disk by kernel
> if you put backend on nvdimm, you should get 2 without sync as well (see pmem=on property)
> 
> just do not forget that sync is not free, so if #1 is acceptable I'd avoid explicit sync.
> 
> 
> > Please point out where I am misunderstanding.
> >
> > Thanks,
> > eric
[...]



  reply	other threads:[~2021-05-20 11:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 20:57 [PATCH v2 0/7] acpi: Error Record Serialization Table, ERST, support for QEMU Eric DeVolder
2021-02-08 20:57 ` [PATCH v2 1/7] ACPI ERST: bios-tables-test.c steps 1 and 2 Eric DeVolder
2021-02-08 20:57 ` [PATCH v2 2/7] ACPI ERST: header file for erst Eric DeVolder
2021-02-08 20:57 ` [PATCH v2 3/7] ACPI ERST: support for ACPI ERST feature Eric DeVolder
2021-04-06 19:31   ` Igor Mammedov
2021-04-09 15:54     ` Eric DeVolder
2021-04-14  9:17       ` Igor Mammedov
2021-05-03 15:49         ` Eric DeVolder
2021-05-03 17:07           ` Igor Mammedov
2021-05-17 15:01             ` Eric DeVolder
2021-05-17 16:31               ` Igor Mammedov
2021-05-18 17:08                 ` Eric DeVolder
2021-05-20 11:00                   ` Igor Mammedov [this message]
2021-05-25 20:22                     ` Eric DeVolder
2021-05-25 21:43                       ` Igor Mammedov
2021-02-08 20:57 ` [PATCH v2 4/7] ACPI ERST: build step for ACPI ERST Eric DeVolder
2021-04-06 19:17   ` Igor Mammedov
2021-02-08 20:57 ` [PATCH v2 5/7] ACPI ERST: support ERST for x86 guest Eric DeVolder
2021-02-08 20:57 ` [PATCH v2 6/7] ACPI ERST: qtest for ERST Eric DeVolder
2021-02-08 20:57 ` [PATCH v2 7/7] ACPI ERST: bios-tables-test.c step 5 Eric DeVolder
2021-03-01 19:04 ` [PATCH v2 0/7] acpi: Error Record Serialization Table, ERST, support for QEMU Eric Devolder
2021-04-01 13:44   ` Michael S. Tsirkin
2021-05-14 13:57 ` Michael S. Tsirkin
2021-05-14 14:12   ` Eric DeVolder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210520130047.1a89d520@redhat.com \
    --to=imammedo@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=ehabkost@redhat.com \
    --cc=eric.devolder@oracle.com \
    --cc=jusual@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).