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.133.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 4A0401BD038 for ; Thu, 2 Jan 2025 22:30:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735857016; cv=none; b=SjRX3oaHOt5kuiMk4YSEwoPp58GmGs8sdE/ekDLRFY0V2XO7Y6JGtlBVrYnm/B/rvcu6aq9+buEjBTCaBjI6oVc9SSFQtbjuZ2rRH6syfYd1brhb3czswfP6fOGHweF9OWN1E2u6g5LQW/pB9OPBJCdyGAD5n/cQszmaiPR8v8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735857016; c=relaxed/simple; bh=hMSNwlRgNE/L7bMLE5kvRjjZbQ5lbZsTS2EvxU5bg0A=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LlSE2qJc9A9BB0mB26Os3POHjY5we7pisuNBTEP9dxz8NpwOD/o+kHmOyfiyE+OFhjleoAG+6IO/oCGQBx4HVCnd7RdIxM57Xm//iIAwJzIuNfX38rsO7Rzf4QRfYZ5miKp7BXTXtLc4XmWMqh2OJd0z3WFeV0pw9AzhsD+BeSE= 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=Oy0oI120; arc=none smtp.client-ip=170.10.133.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="Oy0oI120" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735857013; 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=+ppthJ8pAwyxfIkRpsIYKpDcDgPdS4EZir8kbY1qAI8=; b=Oy0oI120Z/Jmf9jkj/uvOym0wLzqpH6Xt4iVAsQ5gsYzINtEJIqovFBvtjbCoJtbKvju0F B/CvFCjutTSDcZc9BXSZMMQN6C2LQ77LJ1NZpNkfldlt3HISZPl9kMaNeEUBdG4nT9UlCu oZJBUUrtYm3XqG3TzGfsH7JN9eNnGlA= Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-34-ICrafsAwNamDPMoy_FFKMA-1; Thu, 02 Jan 2025 17:30:11 -0500 X-MC-Unique: ICrafsAwNamDPMoy_FFKMA-1 X-Mimecast-MFC-AGG-ID: ICrafsAwNamDPMoy_FFKMA Received: by mail-io1-f71.google.com with SMTP id ca18e2360f4ac-84990d44b31so30334639f.3 for ; Thu, 02 Jan 2025 14:30:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735857011; x=1736461811; h=content-transfer-encoding:mime-version: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=+ppthJ8pAwyxfIkRpsIYKpDcDgPdS4EZir8kbY1qAI8=; b=BJoLZhi9G2bf3yueHC/3V8JaDlNmGbPuLfqm/iBHHpYpuDVIwB0Sf1uOQBe/v45IMQ iYbA3ULSbDSKDXFTGY54DmvY+HCy7V6gJtmW/RvoZgnUpClXBye7tFPMRkpuV4XvGaCB naMAZo/8QH/XIPLXKNT5Er/uBn/H1XWEAwPIMQZnV/OKqjE+7kmsk1CVGszlWCG6k4yF Z9puMdRDWvfwoyBAe2MACKDyUrWLmYTCV5hP/IWiR577G4U1UKkJrbSZcs28RaEHXvt8 YCvjlSME5lfnXFu/yiq/XTFGy15soTZzjOb13otlVFicjyPDXcDa+eAe70hfmPXOVoKf +YFQ== X-Forwarded-Encrypted: i=1; AJvYcCU74YecnX5xf53j/Lt6fiQSTYeb8xCKZDHZe/MzoQPDrZ8O0YlpOgGKtkvlaqM1ViwyE7dp6aSGrratI80=@vger.kernel.org X-Gm-Message-State: AOJu0YxDyBwY9rU3WHmwZGatt/+21+yHV7NcJer+Ok8FFsN9NwDOTmrH pzp1fMjIrYY4uoSS8CiG/wH4hA4htqlca1YffDYiYSeyiwdyJYnaIxDSeKs6mG7xX/Jh68ZzppE Lzgn9+Z32fAwjP7cpEKBCN3HkZC6K75k685bg8bOjqH2qmhw2Ig6ehiy3FB9MWQ== X-Gm-Gg: ASbGncutLlT3kQrF/ZQwqOD/szjW1rUYGyDSjGOYonDm/G7A+/xj4XfAIYSj59k5Stw uSESO5kHdAwUrrUdcm89LpbUyZVK8ZICYCgQK7+wi+RiLIiFRWLmCLIDKsYbHU4k4Oip3sa7B1I CTfZ0TnHbHi3i173wcKg5yo3p8y/lFIwG+Ch2DdnDxvwHQEfz9p0dFXKRUvUNvPVY14nW3gEt26 UGmHdvj/5Vur4CqAGx5ObQOtvGCHaQivG/tx4zf0cR9frqG2jR7UfseYs/T X-Received: by 2002:a05:6e02:3882:b0:3a7:be5c:1422 with SMTP id e9e14a558f8ab-3c2d479cd10mr114585225ab.3.1735857010839; Thu, 02 Jan 2025 14:30:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IFFf9jv7Iv+7P0Jwzyi8R0s6ylOlwCQGbJ3sK5sdytj6nlWH/jJpR3jV/czJGVg1XMsOpKNbQ== X-Received: by 2002:a05:6e02:3882:b0:3a7:be5c:1422 with SMTP id e9e14a558f8ab-3c2d479cd10mr114585115ab.3.1735857010375; Thu, 02 Jan 2025 14:30:10 -0800 (PST) Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3c0deccf405sm79134065ab.29.2025.01.02.14.30.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jan 2025 14:30:09 -0800 (PST) Date: Thu, 2 Jan 2025 15:30:08 -0700 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: <20250102153008.301730f3.alex.williamson@redhat.com> In-Reply-To: <099e0e1215f34d64a4ae698b90ee372c@huawei.com> References: <20241219091800.41462-1-liulongfang@huawei.com> <20241219091800.41462-2-liulongfang@huawei.com> <099e0e1215f34d64a4ae698b90ee372c@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) 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 Thu, 19 Dec 2024 10:01:03 +0000 Shameerali Kolothum Thodi wrote: > > -----Original Message----- > > From: liulongfang > > Sent: Thursday, December 19, 2024 9:18 AM > > To: alex.williamson@redhat.com; jgg@nvidia.com; Shameerali Kolothum > > Thodi ; Jonathan Cameron > > > > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org; > > linuxarm@openeuler.org; liulongfang > > Subject: [PATCH v2 1/5] hisi_acc_vfio_pci: fix XQE dma address error > > > > The dma addresses of EQE and AEQE are wrong after migration and > > results in guest kernel-mode encryption services failure. > > Comparing the definition of hardware registers, we found that > > there was an error when the data read from the register was > > combined into an address. Therefore, the address combination > > sequence needs to be corrected. > > > > Even after fixing the above problem, we still have an issue > > where the Guest from an old kernel can get migrated to > > new kernel and may result in wrong data. > > > > In order to ensure that the address is correct after migration, > > if an old magic number is detected, the dma address needs to be > > updated. > > > > Fixes:b0eed085903e("hisi_acc_vfio_pci: Add support for VFIO live > > migration") > > Signed-off-by: Longfang Liu > > --- > > .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 34 +++++++++++++++---- > > .../vfio/pci/hisilicon/hisi_acc_vfio_pci.h | 9 ++++- > > 2 files changed, 36 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > > b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > > index 451c639299eb..8518efea3a52 100644 > > --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > > +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > > @@ -350,6 +350,27 @@ static int vf_qm_func_stop(struct hisi_qm *qm) > > return hisi_qm_mb(qm, QM_MB_CMD_PAUSE_QM, 0, 0, 0); > > } > > > > +static int vf_qm_magic_check(struct acc_vf_data *vf_data) > > +{ > > + switch (vf_data->acc_magic) { > > + case ACC_DEV_MAGIC_V2: > > + break; > > + case ACC_DEV_MAGIC_V1: > > + /* Correct dma address */ > > + vf_data->eqe_dma = vf_data- > > >qm_eqc_dw[QM_XQC_ADDR_HIGH]; > > + vf_data->eqe_dma <<= QM_XQC_ADDR_OFFSET; > > + vf_data->eqe_dma |= vf_data- > > >qm_eqc_dw[QM_XQC_ADDR_LOW]; > > + vf_data->aeqe_dma = vf_data- > > >qm_aeqc_dw[QM_XQC_ADDR_HIGH]; > > + vf_data->aeqe_dma <<= QM_XQC_ADDR_OFFSET; > > + vf_data->aeqe_dma |= vf_data- > > >qm_aeqc_dw[QM_XQC_ADDR_LOW]; > > + break; > > + default: > > + return -EINVAL; > > + } > > + > > + return 0; > > +} > > + > > static int vf_qm_check_match(struct hisi_acc_vf_core_device > > *hisi_acc_vdev, > > struct hisi_acc_vf_migration_file *migf) > > { > > @@ -363,7 +384,8 @@ static int vf_qm_check_match(struct > > hisi_acc_vf_core_device *hisi_acc_vdev, > > if (migf->total_length < QM_MATCH_SIZE || hisi_acc_vdev- > > >match_done) > > return 0; > > > > - if (vf_data->acc_magic != ACC_DEV_MAGIC) { > > + ret = vf_qm_magic_check(vf_data); > > + if (ret) { > > dev_err(dev, "failed to match ACC_DEV_MAGIC\n"); > > return -EINVAL; > > } > > @@ -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; > > > > @@ -496,12 +518,12 @@ static int vf_qm_read_data(struct hisi_qm > > *vf_qm, struct acc_vf_data *vf_data) > > return -EINVAL; > > > > /* Every reg is 32 bit, the dma address is 64 bit. */ > > - vf_data->eqe_dma = vf_data->qm_eqc_dw[1]; > > + vf_data->eqe_dma = vf_data->qm_eqc_dw[QM_XQC_ADDR_HIGH]; > > vf_data->eqe_dma <<= QM_XQC_ADDR_OFFSET; > > - vf_data->eqe_dma |= vf_data->qm_eqc_dw[0]; > > - vf_data->aeqe_dma = vf_data->qm_aeqc_dw[1]; > > + vf_data->eqe_dma |= vf_data->qm_eqc_dw[QM_XQC_ADDR_LOW]; > > + vf_data->aeqe_dma = vf_data- > > >qm_aeqc_dw[QM_XQC_ADDR_HIGH]; > > vf_data->aeqe_dma <<= QM_XQC_ADDR_OFFSET; > > - vf_data->aeqe_dma |= vf_data->qm_aeqc_dw[0]; > > + vf_data->aeqe_dma |= vf_data- > > >qm_aeqc_dw[QM_XQC_ADDR_LOW]; > > > > /* Through SQC_BT/CQC_BT to get sqc and cqc address */ > > ret = qm_get_sqc(vf_qm, &vf_data->sqc_dma); > > diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.h > > b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.h > > index 245d7537b2bc..2afce68f5a34 100644 > > --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.h > > +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.h > > @@ -39,6 +39,9 @@ > > #define QM_REG_ADDR_OFFSET 0x0004 > > > > #define QM_XQC_ADDR_OFFSET 32U > > +#define QM_XQC_ADDR_LOW 0x1 > > +#define QM_XQC_ADDR_HIGH 0x2 > > + > > #define QM_VF_AEQ_INT_MASK 0x0004 > > #define QM_VF_EQ_INT_MASK 0x000c > > #define QM_IFC_INT_SOURCE_V 0x0020 > > @@ -50,10 +53,14 @@ > > #define QM_EQC_DW0 0X8000 > > #define QM_AEQC_DW0 0X8020 > > > > +enum acc_magic_num { > > + ACC_DEV_MAGIC_V1 = 0XCDCDCDCDFEEDAACC, > > + ACC_DEV_MAGIC_V2 = 0xAACCFEEDDECADEDE, > > > I think we have discussed this before that having some kind of > version info embed into magic_num will be beneficial going > forward. ie, may be use the last 4 bytes for denoting version. > > ACC_DEV_MAGIC_V2 = 0xAACCFEEDDECA0002 > > The reason being, otherwise we have to come up with a random > magic each time when a fix like this is required in future. Overloading the magic value like this is a bit strange. Typically the magic value should be the cookie that identifies the data blob as generated by this driver and a separate version field would identify any content or format changes. In the mtty driver I included a magic field along with major and minor versions to provide this flexibility. I wonder why we wouldn't do something similar here rather than create this combination magic/version field. It's easy enough to append a couple fields onto the structure or redefine a v2 structure to use going forward. There's even a padding field in the structure already that could be repurposed. I see v3 went on to modify the v2 magic as described here, but there's nothing to suggest the use of these latter bytes as anything other than a slightly different random magic value. Minimally the suggestion should have resulted in 6-bytes of magic and 2-bytes of version (iiuc), but there's no code to support that nor would I recommend that layout versus the alternatives above. Thanks, Alex