From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:504:1dd4:b0:1be9:327d:8ee3 with SMTP id b20csp183103nji; Thu, 11 Jul 2024 06:34:46 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXH9lO5btq1jJRRsCI4UPADZKD9NkecBxlCqgAezYeNuo7EKUVj1KwjK625/R2HPlmNoR6g/RLoz3i3ly3IyH06e/s79MFD X-Google-Smtp-Source: AGHT+IGF7p/0B3PgZnpEVIGxrU3tnM7nWALeeFdQRastdCbOgI7YW1FPKWAyt3kvha2Xh//bX0YY X-Received: by 2002:a05:6808:1455:b0:3d9:324a:3c9 with SMTP id 5614622812f47-3d93c0385c1mr11451333b6e.11.1720704886632; Thu, 11 Jul 2024 06:34:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1720704886; cv=none; d=google.com; s=arc-20160816; b=XiETVgRp+UfPuFtqOQZnFIxkXNpLizV89mPZlNnt2yhQTWsOyCwu16MKcCUCgtiGdL /ROIN5mb+tdrm/B15tWwHL/fId1JYFS24HonoKojCsahGTrzCaaROhH4GZEBw+STFod3 T5Og0IKps+FBKX22iObLX4S2PWDizy5yboiiIu9on582iVZm2pS1GTSDu5bjdaCBn3UZ AeUWbNkKOrO9ZZayU/lFOBa2fS5weRG3eUJu1qI2fKu+Jae/VLhlWe5A/CiWPs2hOieR xaeRTosCLosaD4DiRHdW6GTD7Fa7JJXKUgLmDTgbwGwqcnnPPLBE8apwnBTWlWmR0xii owqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:mime-version:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature :dkim-signature:dkim-signature:dkim-signature; bh=U7SpHLWVoLqmhYWQJuF8+xa5T3BrIlA2GBMHiEMBjcI=; fh=umL8zxbWF4W2pS9nVgc4z5DWwZX8pLHcZx531lKXiRo=; b=gOTgmuCM0/u2onVnrLZEQjbiGuB730U2GN2LOxuSfJ5blmf1JAhB6id5hRFT5Z7a7U v7bDBmr7l3f7nHVk8XQSLgHAFU+qGu10itNLAgZDqfkodqQcgpzAzqexkiyvgfmLpLF8 AL2bonzkSFN1l9liBasnMqfo8k+Sze7WeZ+fcWtFnIKXDYAb6oQEP38USIHrk56YJ+0S cerkThCyz1dYfNz/bhnvBgYnd6iif4EQ00a01FrN4bW8Nnk2WjFg/A6fVIR/wOf4nngJ sOQjsYgjLvrG4OJWm/0/WnNovHCIhE2ubGmR6N2CgErytTO3PoCpvMWw4d5ZKGMur9rt VCEQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=oXXq4Ayq; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=x90lgCvr; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=oXXq4Ayq; dkim=neutral (no key) header.i=@nongnu.org header.s=susede2_ed25519; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id af79cd13be357-79f190d8702si787846185a.628.2024.07.11.06.34.46 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Jul 2024 06:34:46 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=oXXq4Ayq; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=x90lgCvr; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=oXXq4Ayq; dkim=neutral (no key) header.i=@nongnu.org header.s=susede2_ed25519; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRtwX-0003vf-Ve; Thu, 11 Jul 2024 09:34:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRtwC-0002QM-Dx; Thu, 11 Jul 2024 09:34:31 -0400 Received: from smtp-out1.suse.de ([195.135.223.130]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sRtwA-0003LY-81; Thu, 11 Jul 2024 09:34:20 -0400 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9C88521B59; Thu, 11 Jul 2024 13:34:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1720704855; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U7SpHLWVoLqmhYWQJuF8+xa5T3BrIlA2GBMHiEMBjcI=; b=oXXq4AyqiXlEJx627PORaWEtfXPtn3XQbnvdOGqsUXmiRHC1IQonXDYbuFp0tNIokTWP5Z e0fDByQk5NHtl/UwbBdTugM+6h8BXUaZGkSDIQ4nfgWfngPWxbCGSFjBJ6BLkGc0MHkS/F Cg9+RUjhX77oJVpgnmwFTibOT19BDV0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1720704855; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U7SpHLWVoLqmhYWQJuF8+xa5T3BrIlA2GBMHiEMBjcI=; b=x90lgCvrNo+45VBoDkbc18N7iLM0IXg/foUn+3LuM56DzLYlGeNo88wTHkJZgDfpG5hThK Bw4lm866fYht7FBw== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=oXXq4Ayq; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=x90lgCvr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1720704855; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U7SpHLWVoLqmhYWQJuF8+xa5T3BrIlA2GBMHiEMBjcI=; b=oXXq4AyqiXlEJx627PORaWEtfXPtn3XQbnvdOGqsUXmiRHC1IQonXDYbuFp0tNIokTWP5Z e0fDByQk5NHtl/UwbBdTugM+6h8BXUaZGkSDIQ4nfgWfngPWxbCGSFjBJ6BLkGc0MHkS/F Cg9+RUjhX77oJVpgnmwFTibOT19BDV0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1720704855; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U7SpHLWVoLqmhYWQJuF8+xa5T3BrIlA2GBMHiEMBjcI=; b=x90lgCvrNo+45VBoDkbc18N7iLM0IXg/foUn+3LuM56DzLYlGeNo88wTHkJZgDfpG5hThK Bw4lm866fYht7FBw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1BEC5139E0; Thu, 11 Jul 2024 13:34:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id I2LrNFbfj2ZGfQAAD6G6ig (envelope-from ); Thu, 11 Jul 2024 13:34:14 +0000 From: Fabiano Rosas To: Peter Xu Cc: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org, qemu-block@nongnu.org, Laurent Vivier , Tyrone Ting , Bin Meng , Hao Wu , Francisco Iglesias , Paolo Bonzini , Thomas Huth , =?utf-8?Q?C=C3=A9dric?= Le Goater , qemu-arm@nongnu.org, Joel Stanley , Sai Pavan Boddu , devel@lists.libvirt.org, Luc Michel , =?utf-8?Q?C?= =?utf-8?Q?=C3=A9dric?= Le Goater Subject: Re: [PATCH v3 06/17] hw/sd/sdcard: Do not store vendor data on block drive (CMD56) In-Reply-To: References: <20240627162232.80428-7-philmd@linaro.org> <87cynmfggx.fsf@suse.de> <87a5ipfigb.fsf@suse.de> <874j8xfc9s.fsf@suse.de> <871q41f2pk.fsf@suse.de> <87ttgxdj1p.fsf@suse.de> Date: Thu, 11 Jul 2024 10:34:12 -0300 Message-ID: <87plrkdpd7.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 9C88521B59 X-Spam-Score: 0.99 X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [0.99 / 50.00]; SUSPICIOUS_RECIPS(1.50)[]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWELVE(0.00)[18]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[linaro.org,nongnu.org,redhat.com,nuvoton.com,gmail.com,google.com,amd.com,kaod.org,jms.id.au,lists.libvirt.org]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.de:dkim]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; DKIM_TRACE(0.00)[suse.de:+] X-Spamd-Bar: / Received-SPF: pass client-ip=195.135.223.130; envelope-from=farosas@suse.de; helo=smtp-out1.suse.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org X-TUID: HkiGVJLx8y1d Peter Xu writes: > On Wed, Jul 10, 2024 at 06:38:26PM -0300, Fabiano Rosas wrote: >> Peter Xu writes: >> >> > On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote: >> >> Peter Xu writes: >> >> >> >> > On Wed, Jul 10, 2024 at 01:21:51PM -0300, Fabiano Rosas wrote: >> >> >> It's not about trust, we simply don't support migrations other than >> >> >> n->n+1 and (maybe) n->n-1. So QEMU from 2016 is certainly not included. >> >> > >> >> > Where does it come from? I thought we suppport that.. >> >> >> >> I'm taking that from: >> >> >> >> docs/devel/migration/main.rst: >> >> "In general QEMU tries to maintain forward migration compatibility >> >> (i.e. migrating from QEMU n->n+1) and there are users who benefit from >> >> backward compatibility as well." >> >> >> >> But of course it doesn't say whether that comes with a transitive rule >> >> allowing n->n+2 migrations. >> > >> > I'd say that "i.e." implies n->n+1 is not the only forward migration we >> > would support. >> > >> > I _think_ we should support all forward migration as long as the machine >> > type matches. >> > >> >> >> >> > >> >> > The same question would be: are we requesting an OpenStack cluster to >> >> > always upgrade QEMU with +1 versions, otherwise migration will fail? >> >> >> >> Will an OpenStack cluster be using upstream QEMU? If not, then that's a >> > >> > It's an example to show what I meant! :) Nothing else. Definitely not >> > saying that everyone should use an upstream released QEMU (but in reality, >> > it's not a problem, I think, and I do feel like people use them, perhaps >> > more with the stable releases). >> > >> >> question for the distro. In a very practical sense, we're not requesting >> >> anything. We barely test n->n+1/n->n-1, even if we had a strong support >> >> statement I wouldn't be confident saying migration from QEMU 2.7 -> QEMU >> >> 9.1 should succeed. >> > >> > No matter what we test in CI, I don't think we should break that for >1 >> > versions.. I hope 2.7->9.1 keeps working, otherwise I think it's legal to >> > file a bug by anyone. >> > >> > For example, I randomly fetched a bug report: >> > >> > https://gitlab.com/qemu-project/qemu/-/issues/1937 >> > >> > QEMU version: 6.2 and 7.2.5 >> > >> > And I believe that's the common case even for upstream. If we don't do >> > that right for upstream, it can be impossible tasks for downstream and for >> > all of us to maintain. >> >> But do we do that right currently? I have no idea. Have we ever done >> it? And we're here discussing a hypothetical 2.7->9.1 ... >> >> So we cannot reuse the UNUSED field because QEMU from 2016 might send >> their data and QEMU from 2024 would interpret it wrong. >> >> How do we proceed? Add a subsection. And make the code survive when >> receiving 0. >> >> @Peter is that it? What about backwards-compat? We'll need a property as >> well it seems. > > Compat property is definitely one way to go, but I think it's you who more > or less persuaded me that reusing it seems possible! At least I can't yet > think of anything bad if it's ancient unused buffers. Since we're allowing any old QEMU version to migrate to the most recent one, we need to think of the data that was there before the introduction of the UNUSED field. If that QEMU version is used, then it's not going to be zeroes on the stream, but whatever data was there before. The new QEMU will be expecting the vendor_data introduced in this patch. > And that's why I was asking about a sane way to describe the "magic > year".. And I was very serious when I said "6 years" to follow the > deprecation of machine types, because it'll be something we can follow > to say when an unused buffer can be obsolete and it could make some > sense: if we will start to deprecate machine types, then it may not > make sense to keep any UNUSED compatible forever, after all. > Is there an easy way to look at a field and tell in which machine type's timeframe it was introduced? If the machine type of that era has been removed, then the field is free to go as well. I'd prefer if we had a hard link instead of just counting years. Maybe we should to that mapping at the machine deprecation time? As in, "look at the unused fields introduced in that timeframe and mark them free". > And we need that ruler to be as accurate as "always 6 years to follow > machine type deprecation procedure", in case someone else tomorrow asks us > something that was only UNUSED since 2018. We need a rule of thumb if we > want to reuse it, and if all of you agree we can start with this one, > perhaps with a comment above the field (before we think all through and > make it a rule on deprecating UNUSED)?