From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 888CE1DA32 for ; Tue, 14 Jan 2025 13:55:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736862903; cv=none; b=q4qA03dxTzeGeDkxP4PEuWIS3awJX3w7cT/Ws4jt/ozRecDuQdTp9EDKaeQm8diEAMl/j7IvebJQ6PIKqUgHarm2rmdEGn8KiVKq1zllWl7s7+VSKnLxe/N3m7s4bNooftTh1xLCdlF3YxBzUqh3Zl9CLIGsY6y4YDi57VNZX54= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736862903; c=relaxed/simple; bh=KQc76jw2yVO1YzP3I6M3XTVo7DV1uXdFjbmr/DPnRL8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H8wzPj8Sa8g6VJrXQV5g04aFdF6UxJ4MwPfzh7FIcOz1qqrRrdVrsJDH6Y6X+POS5eju7Q7iju3ODtB+FgI2Lp8UFxhDJQwt614kQ1EQmjhcYSOiZ+hCl1p5lC5ARXZxsF7ktMXBaK3L+z/4SnnWfOwvOOdbIDyPldSmnPNJyCY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ht6yMadm; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ht6yMadm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736862900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sPMtOWaxET36PC3zKH8M3ARBY50nMtMjbmhfciNkjD0=; b=ht6yMadmkSZNeKvT6hyKqx7udOVuPMPTYMlocDLnf4utLE5h9EqfD1WTyIok/Vf7WAs72G Ebm0myGuOI9HoMhhG798x1HYb1EE/C7IwWBptLoDcHfInHdhl/uDfdPX2WOQQ22An9lHtW fg+M4enA8IdnXNnRVNWU8jFbD10vWEY= Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-131-fNBIMNd0OgWpFn6QgkGtYQ-1; Tue, 14 Jan 2025 08:54:59 -0500 X-MC-Unique: fNBIMNd0OgWpFn6QgkGtYQ-1 X-Mimecast-MFC-AGG-ID: fNBIMNd0OgWpFn6QgkGtYQ Received: by mail-io1-f69.google.com with SMTP id ca18e2360f4ac-84a3a4ec598so46414739f.2 for ; Tue, 14 Jan 2025 05:54:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736862898; x=1737467698; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=sPMtOWaxET36PC3zKH8M3ARBY50nMtMjbmhfciNkjD0=; b=pl3cEZAFA2MwjrcppCh6mtPlfMO4t6PGinTveDgorQAOPF9VWEDVer6E2Q7Z1EvlgA OnWP7eFWrNZPHV1sDc0/Pw2hXFqeOTRp2nK0MV4CPQgRgABZcrWhiUTFUOM7SUzj3ceQ BwDp1Eoe3xB9LPtCauwle4GC/Mif990twQbh6ZxfYC3nIRs/cJKDeNhdc9yDf0IIq9xo R/I3RqQ5VrJ3Y0R9gNncqhbHfruBGcDRt3RAIjAL+COvcMWyJP7pRBcZOOonrDLpgg18 l8dx5RrGFhUp07hKJiiM/87hPqMW3ySOVqHPjnkpwSonghP6SBZKA5EC8it5r/+kf0Vq oChw== X-Forwarded-Encrypted: i=1; AJvYcCWAFGzmwULxcD3fWiOkCVqSncBc9XNorFBsE7P4aXkahlz+q8pOyXT6dRg892WPhLGWSz3m0j/w9Lj65sM=@vger.kernel.org X-Gm-Message-State: AOJu0YxjSBrnZiwkkSJiKCALZP8uAJqBgQiu00poWg48Z79JMfPk86GC EQUfGZ+yDoZAh6wNQ2ZsUzQbGum/x16pGmn5D5LUAxP3hUQlmCe5NScuuEDs/ZMN6sPrPNhwVxM IiLO0kFt5Wb59grD3GHlE2Gfqu02MRGXryVQBjbrn4rle9S593bv6DpQkjhX08Q== X-Gm-Gg: ASbGncspCC/YGYM5Hbz1FRm2kKAooqF5fSGgIjlTsRj1ZUr3SxlxNAByM7p2R18VJN0 agSGDDamNMmjKpZZQwJ0e5kONmlUc1fQSbInm4rcMl1TJ7w80adhp5BDD8fPvby6KtfqdpxH/H3 jA20sed4la9Is1DISNW82P5YgZ2BbdmHBD9Gczjg/y1r0nJaIc0yoxEa4zc4RWGJzqkh5q45xef XHd4yt6D/ZIBuyvbTBRJQctZ0udPKiz8iSmjoTnPcrQ566gUMeQwec/9SzB X-Received: by 2002:a05:6e02:1f09:b0:3a7:8720:9ded with SMTP id e9e14a558f8ab-3ce3a86b051mr49009055ab.2.1736862898461; Tue, 14 Jan 2025 05:54:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IGtgL8iY7ZCRJa4sPauV5DvThBPPh4mlMgFqmqDoh9/JUdKV2f/oArrE7hAcXlNoOXAHJFgCg== X-Received: by 2002:a05:6e02:1f09:b0:3a7:8720:9ded with SMTP id e9e14a558f8ab-3ce3a86b051mr49008985ab.2.1736862898111; Tue, 14 Jan 2025 05:54:58 -0800 (PST) Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3ce4adb378asm34022015ab.19.2025.01.14.05.54.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 05:54:57 -0800 (PST) Date: Tue, 14 Jan 2025 08:54:43 -0500 From: Alex Williamson To: Shameerali Kolothum Thodi Cc: liulongfang , "jgg@nvidia.com" , Jonathan Cameron , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linuxarm@openeuler.org" Subject: Re: [PATCH v2 1/5] hisi_acc_vfio_pci: fix XQE dma address error Message-ID: <20250114085443.17777cb0.alex.williamson@redhat.com> In-Reply-To: <8225389dd537497c9753cf0a321964e4@huawei.com> References: <20241219091800.41462-1-liulongfang@huawei.com> <20241219091800.41462-2-liulongfang@huawei.com> <099e0e1215f34d64a4ae698b90ee372c@huawei.com> <20250102153008.301730f3.alex.williamson@redhat.com> <4d48db10-23e1-1bb4-54ea-4c659ab85f19@huawei.com> <20250113083441.0fb7afa3.alex.williamson@redhat.com> <20250113144516.22a17af8.alex.williamson@redhat.com> <80a4e398-ad29-cce8-4a52-ce2a5f6a308c@huawei.com> <8225389dd537497c9753cf0a321964e4@huawei.com> Organization: Red Hat Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 14 Jan 2025 08:07:43 +0000 Shameerali Kolothum Thodi wrote: > > -----Original Message----- > > From: liulongfang > > Sent: Tuesday, January 14, 2025 3:18 AM > > To: Alex Williamson > > Cc: Shameerali Kolothum Thodi > > ; jgg@nvidia.com; Jonathan > > Cameron ; kvm@vger.kernel.org; linux- > > kernel@vger.kernel.org; linuxarm@openeuler.org > > Subject: Re: [PATCH v2 1/5] hisi_acc_vfio_pci: fix XQE dma address error > > > > [...] > > > > @@ -418,7 +440,7 @@ static int vf_qm_get_match_data(struct > > hisi_acc_vf_core_device *hisi_acc_vdev, > > > int vf_id = hisi_acc_vdev->vf_id; > > > int ret; > > > > > > - vf_data->acc_magic = ACC_DEV_MAGIC; > > > + vf_data->acc_magic = ACC_DEV_MAGIC_V2; > > > /* Save device id */ > > > vf_data->dev_id = hisi_acc_vdev->vf_dev->device; > > > > > > Thanks, > > > Alex > > > > > >>> > > >>> As for the compatibility issues between old and new versions in the > > >>> future, we do not need to reserve version numbers to deal with them > > >>> now. Because before encountering specific problems, our design may > > be redundant. > > >> > > >> A magic value + version number would prevent the need to replace the > > >> magic value every time an issue is encountered, which I think was > > >> also Shameer's commit, which is not addressed by forcing the > > >> formatting of a portion of the magic value. None of what you're > > >> trying to do here precludes a new data structure for the new magic > > >> value or defining the padding fields for different use cases. > > >> Thanks, > > >> > > >> Alex > > > > > > > If we want to use the original magic number, we also need to add the major > > and minor version numbers. It does not cause compatibility issues and can > > only reuse the original u64 memory space. > > > > This is also Shameerali's previous plan. Do you accept this plan? > > The suggestion here is to improve my previous plan.. ie, instead of overloading > the V2 MAGIC with version info, introduce version(major:minor) separately. > > Something like, > > Rename old MAGIC as MAGIC_V1 > > Introduce new MAGIC as MAGIC_V2 > > Repurpose any padding or reserved fields in struct vf_data for major:minor > version fields. The idea of introducing these major:minor is for future use > where instead of coming up with a new MAGIC data every time we can > increment the version for bug fixes and features if required. Yes, there's no suggestion to use the original magic value, that magic number describes a non-extensible data structure. As Shameer indicates, use a new magic value and define within the data structure specified by that magic value major:minor number and a scheme for defining compatible (if any) and incompatible updates. Thanks, Alex