All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.