From: Alexander Graf <graf@amazon.de>
To: "Catangiu, Adrian Costin" <acatan@amazon.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Jann Horn <jannh@google.com>
Cc: Willy Tarreau <w@1wt.eu>,
"MacCarthaigh, Colm" <colmmacc@amazon.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
"Eric Biggers" <ebiggers@kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
kernel list <linux-kernel@vger.kernel.org>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
"bonzini@gnu.org" <bonzini@gnu.org>,
"Singh, Balbir" <sblbir@amazon.com>,
"Weiss, Radu" <raduweis@amazon.com>,
"oridgar@gmail.com" <oridgar@gmail.com>,
"ghammer@redhat.com" <ghammer@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Qemu Developers" <qemu-devel@nongnu.org>,
KVM list <kvm@vger.kernel.org>,
"Michal Hocko" <mhocko@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Pavel Machek" <pavel@ucw.cz>,
Linux API <linux-api@vger.kernel.org>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
linux-s390 <linux-s390@vger.kernel.org>,
"areber@redhat.com" <areber@redhat.com>,
"Pavel Emelyanov" <ovzxemul@gmail.com>,
Andrey Vagin <avagin@gmail.com>,
"Mike Rapoport" <rppt@kernel.org>,
Dmitry Safonov <0x7f454c46@gmail.com>,
"Pavel Tikhomirov" <ptikhomirov@virtuozzo.com>,
"gil@azul.com" <gil@azul.com>,
"asmehra@redhat.com" <asmehra@redhat.com>,
"dgunigun@redhat.com" <dgunigun@redhat.com>,
"vijaysun@ca.ibm.com" <vijaysun@ca.ibm.com>
Subject: Re: [PATCH v2] drivers/virt: vmgenid: add vm generation id driver
Date: Mon, 7 Dec 2020 14:23:06 +0100 [thread overview]
Message-ID: <ee2ccb9f-c689-710d-0297-63d8fc2c98dd@amazon.de> (raw)
In-Reply-To: <ded94f0f-9c60-38b3-6217-03d3c0edd613@amazon.com>
On 27.11.20 18:17, Catangiu, Adrian Costin wrote:
>
> On 18/11/2020 12:30, Alexander Graf wrote:
>>
>>
>> On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
>>> - Future improvements
>>>
>>> Ideally we would want the driver to register itself based on devices'
>>> _CID and not _HID, but unfortunately I couldn't find a way to do that.
>>> The problem is that ACPI device matching is done by
>>> '__acpi_match_device()' which exclusively looks at
>>> 'acpi_hardware_id *hwid'.
>>>
>>> There is a path for platform devices to match on _CID when _HID is
>>> 'PRP0001' - but this is not the case for the Qemu vmgenid device.
>>>
>>> Guidance and help here would be greatly appreciated.
>>
>> That one is pretty important IMHO. How about the following (probably
>> pretty mangled) patch? That seems to work for me. The ACPI change
>> would obviously need to be its own stand alone change and needs proper
>> assessment whether it could possibly break any existing systems.
>>
>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> index 1682f8b454a2..452443d79d87 100644
>> --- a/drivers/acpi/bus.c
>> +++ b/drivers/acpi/bus.c
>> @@ -748,7 +748,7 @@ static bool __acpi_match_device(struct acpi_device
>> *device,
>> /* First, check the ACPI/PNP IDs provided by the caller. */
>> if (acpi_ids) {
>> for (id = acpi_ids; id->id[0] || id->cls; id++) {
>> - if (id->id[0] && !strcmp((char *)id->id, hwid->id))
>> + if (id->id[0] && !strncmp((char *)id->id, hwid->id,
>> ACPI_ID_LEN - 1))
>> goto out_acpi_match;
>> if (id->cls && __acpi_match_device_cls(id, hwid))
>> goto out_acpi_match;
>> diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
>> index 75a787da8aad..0bfa422cf094 100644
>> --- a/drivers/virt/vmgenid.c
>> +++ b/drivers/virt/vmgenid.c
>> @@ -356,7 +356,8 @@ static void vmgenid_acpi_notify(struct acpi_device
>> *device, u32 event)
>> }
>>
>> static const struct acpi_device_id vmgenid_ids[] = {
>> - {"QEMUVGID", 0},
>> + /* This really is VM_Gen_Counter, but we can only match 8
>> characters */
>> + {"VM_GEN_C", 0},
>> {"", 0},
>> };
>>
>
> Looks legit. I can propose a patch with it, but how do we validate it
> doesn't break any devices?
Mainly by proposing it and seeing what the ACPI maintainers say. Maybe
they have a better idea even. At least this explictly nudges them.
>
>
>>> +2) ASYNC simplified example::
>>> +
>>> + void handle_io_on_vmgenfd(int vmgenfd)
>>> + {
>>> + unsigned genid;
>>> +
>>> + // because of VM generation change, we need to rebuild world
>>> + reseed_app_env();
>>> +
>>> + // read new gen ID - we need it to confirm we've handled update
>>> + read(fd, &genid, sizeof(genid));
>>
>> This is racy in case two consecutive snapshots happen. The read needs
>> to go before the reseed.
>>
> Switched them around like you suggest to avoid confusion.
>
> But I don't see a problem with this race. The idea here is to trigger
> reseed_app_env() which doesn't depend on the generation counter value.
> Whether it gets incremented once or N times is irrelevant, we're just
> interested that we pause execution and reseed before resuming (in
> between these, whether N or M generation changes is the same thing).
>
>>> +3) Mapped memory polling simplified example::
>>> +
>>> + /*
>>> + * app/library function that provides cached secrets
>>> + */
>>> + char * safe_cached_secret(app_data_t *app)
>>> + {
>>> + char *secret;
>>> + volatile unsigned *const genid_ptr = get_vmgenid_mapping(app);
>>> + again:
>>> + secret = __cached_secret(app);
>>> +
*genid_ptr = 1
cached_genid = 1
>>> + if (unlikely(*genid_ptr != app->cached_genid)) {
*genid_ptr = 2
cached_genid = 1
>>> + // rebuild world then confirm the genid update (thru write)
>>> + rebuild_caches(app);
hypervisor takes another snapshot during rebuild_caches(). Resume path
bumps genid
>>> + app->cached_genid = *genid_ptr;
*genid_ptr = 3
cached_genid = 3
>>
>> This is racy again. You need to read the genid before rebuild and set
>> it here.
>>
> I don't see the race. Gen counter is read from volatile mapped mem, on
> detected change we rebuild world, confirm the update back to the driver
> then restart the loop. Loop will break when no more changes happen.
See above. After the outlined course of things, the snapshot will
contain data that will be identical between 2 snapshots.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
next prev parent reply other threads:[~2020-12-07 13:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 15:34 [PATCH v2] drivers/virt: vmgenid: add vm generation id driver Catangiu, Adrian Costin
2020-11-18 10:30 ` Alexander Graf
2020-11-27 17:17 ` Catangiu, Adrian Costin
2020-12-07 13:23 ` Alexander Graf [this message]
2020-11-19 12:02 ` Christian Borntraeger
2020-11-19 12:51 ` Alexander Graf
2020-11-19 13:09 ` Christian Borntraeger
2020-11-19 17:38 ` Mike Rapoport
2020-11-19 18:36 ` Alexander Graf
2020-11-20 21:18 ` Dmitry Safonov
2020-11-27 18:26 ` [PATCH v3] " Catangiu, Adrian Costin
2020-11-28 10:16 ` Mike Rapoport
2020-12-01 18:00 ` Eric W. Biederman
2020-12-07 13:11 ` Alexander Graf
2020-11-20 22:29 ` [PATCH v2] " Jann Horn
2020-11-27 18:22 ` Jann Horn
2020-11-27 19:04 ` Catangiu, Adrian Costin
2020-11-27 20:20 ` Jann Horn
2020-12-07 14:22 ` Alexander Graf
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=ee2ccb9f-c689-710d-0297-63d8fc2c98dd@amazon.de \
--to=graf@amazon.de \
--cc=0x7f454c46@gmail.com \
--cc=Jason@zx2c4.com \
--cc=acatan@amazon.com \
--cc=areber@redhat.com \
--cc=asmehra@redhat.com \
--cc=avagin@gmail.com \
--cc=bonzini@gnu.org \
--cc=borntraeger@de.ibm.com \
--cc=colmmacc@amazon.com \
--cc=corbet@lwn.net \
--cc=dgunigun@redhat.com \
--cc=dwmw@amazon.co.uk \
--cc=ebiggers@kernel.org \
--cc=ghammer@redhat.com \
--cc=gil@azul.com \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=mst@redhat.com \
--cc=oridgar@gmail.com \
--cc=ovzxemul@gmail.com \
--cc=pavel@ucw.cz \
--cc=ptikhomirov@virtuozzo.com \
--cc=qemu-devel@nongnu.org \
--cc=raduweis@amazon.com \
--cc=rafael@kernel.org \
--cc=rppt@kernel.org \
--cc=sblbir@amazon.com \
--cc=tytso@mit.edu \
--cc=vijaysun@ca.ibm.com \
--cc=w@1wt.eu \
/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).