Received-SPF: pass (google.com: domain of linux-kernel+bounces-479-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Zhao, Yan Y" <yan.y.zhao@intel.com>, "kvm@vger.kernel.org"
	<kvm@vger.kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
CC: "pbonzini@redhat.com" <pbonzini@redhat.com>, "seanjc@google.com"
	<seanjc@google.com>, "olvaffe@gmail.com" <olvaffe@gmail.com>, "Lv, Zhiyuan"
	<zhiyuan.lv@intel.com>, "Wang, Zhenyu Z" <zhenyu.z.wang@intel.com>, "Ma,
 Yongwei" <yongwei.ma@intel.com>, "vkuznets@redhat.com" <vkuznets@redhat.com>,
	"wanpengli@tencent.com" <wanpengli@tencent.com>, "jmattson@google.com"
	<jmattson@google.com>, "joro@8bytes.org" <joro@8bytes.org>,
	"gurchetansingh@chromium.org" <gurchetansingh@chromium.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>
Subject: RE: [RFC PATCH] KVM: Introduce KVM VIRTIO device
Thread-Topic: [RFC PATCH] KVM: Introduce KVM VIRTIO device
Thread-Index: AQHaLn1b27525Q6w90S6Q0FOwXgDl7Cp2kUA
Date: Fri, 15 Dec 2023 06:23:48 +0000
Message-ID: <BN9PR11MB5276BE04CBB6D07039086D658C93A@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20231214103520.7198-1-yan.y.zhao@intel.com>
In-Reply-To: <20231214103520.7198-1-yan.y.zhao@intel.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GmfbtgPxjAbwU24/NfrvrhjiwgGpMgZHrRfMWpnGNcEgVSPduSVY1pyLMp2s?=
 =?us-ascii?Q?OjJa8QGvWItb9MIO38MZbHgL479gTFUJTcyig8Hd/ZtKMudMnsvBGm6YOW5l?=
 =?us-ascii?Q?Ds4wZNQeyzr4syvIm6y/DVvkx3ifDHYbOTI0d1EtEgm3+9no2TV/rPWGplvX?=
 =?us-ascii?Q?gjnK9NEZ2Mucxe6J2E4QKwPcweWIRU1+7KRNTaKaPe8QW+Z38ZqougPEdHfw?=
 =?us-ascii?Q?QGgIH/upFiMApVc/zJTNTi9XFi1Wf/BOOi9i/8K9ll5kEgUA8lzneFOrlXeN?=
 =?us-ascii?Q?OwCUnOtXyZciydcqaj9aSK7GYazc1q8Q2dvRRmk9iktkXfKXYEsighwVLO8Y?=
 =?us-ascii?Q?VIkySE8YQqZYvpB/R6ogpip0gN2y4heYgNqD42vY06/wMF/UjFS1W9xFuU1N?=
 =?us-ascii?Q?3UJrBmuEeledXgk10VHrEUq9yHL3NZdJemPveuyJtwIbpQZgXDccHw3mXK4s?=
 =?us-ascii?Q?2+YK+zkEP0q8vRCzfKHOmEm0FfJ3jd638qL7t0JsVahPyOTOiihdaJFSFDhd?=
 =?us-ascii?Q?LeUBUmfmVtkpgTOfco3wbbgmxtqmuhpRyjk79Z/jhqLfz0LVn0b/yyQQFi65?=
 =?us-ascii?Q?OcopqPBG/JYt2kOL7O6uqTg/yT30N16uRQmejv0EEUVT/0VKhIVpOlGGv9wq?=
 =?us-ascii?Q?E+z86/8UeDMCYA3z3HvgYd5qtB4QXL7S16Q0+057LRcaYVsWY/S3fO2RtlVm?=
 =?us-ascii?Q?5PsdH992dQVAwJWlwkSIodGsvabcN657fxYap+011qD4AzgBUNY4iLPARFP5?=
 =?us-ascii?Q?ZhNPz4615kvUdRK7EgIv5W5LaFpgHZh57qSnRpQZlstreeBFJ2tNKuV85ZvA?=
 =?us-ascii?Q?mGoOu7c6xEDnD49kGc7ja5sY84UTxW4zzkBGLf6tiW24Ih6F3IXPAj8RbBBp?=
 =?us-ascii?Q?FokTnoe7XU7GNfX9ZT5awnFve2c5c3Gdvzr7+2RGyGnVZiRSqqe+4lK4G4ZC?=
 =?us-ascii?Q?aUYYAtMstt5pw0O4yheIn6+Kau7ihX9PUXdixqQ3yDLpAZcA0VdeFYXMqu3I?=
 =?us-ascii?Q?Gzt0uJABkyc1/x+gA0lxNHLTnKY1DNiTAhONckWXDy0yej/8j1dODWw+WMxX?=
 =?us-ascii?Q?YEDXZySlIrFnXiQ74v9Wnyo5SShxAsZIOLgQvIGYD0yam9XpGOmASLnNeuUC?=
 =?us-ascii?Q?Y8a0dulBvKO5jhuYv8AMNpzRo7TbyW4nGZV5KdvJDr/VzyCTR0/711SQTayj?=
 =?us-ascii?Q?8jL0vUoNWtpqw3ndg3d/nnb15bsUvN/Bld8hEhCmIDnjIKLkc/Aiyq5uAfg7?=
 =?us-ascii?Q?rvD0Lq+xzVXpxusPPH3+VfV/iehRPLi4w6SksuAH9Z9AaE/Dtz0tJZUMBn3O?=
 =?us-ascii?Q?w920EhIYuSplQlFHiq+fL/v8OxjNws5TTXYC+nwBOnNnfwzY44i49fMyyUD5?=
 =?us-ascii?Q?A67ClM9kudI4piFSLGk5zvrIFjWmJfSWEMXF4wzwrqzaIXCZk6FKoSNKcUWT?=
 =?us-ascii?Q?tnIVGz5q/cbxX8oes8l3g3sAz+ck2Wmfn2i0IrDHAiPoRlixketGrKmS6O2x?=
 =?us-ascii?Q?k9v0ok3w8osFxvC64KjdLdpkYE4ias86BQT+bhCjjDMSeBU0csgrD65+2euy?=
 =?us-ascii?Q?yHMHweR4YRkuKpU4lE8AW7xgL+/m0tJumLd3KFg2?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f6d0069-bfe5-40a2-fddd-08dbfd3665cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2023 06:23:48.0863
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TndMqFFhsNlhIKESW7vlHF4aPWymh9wqYDKsSBhPjnzQSToSCvB/ppYLArIJOgQ7S1qExyjWerDO3Xdl8BYzcg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5610
X-OriginatorOrg: intel.com

> From: Zhao, Yan Y <yan.y.zhao@intel.com>
> Sent: Thursday, December 14, 2023 6:35 PM
>=20
> - For host non-MMIO pages,
>   * virtio guest frontend and host backend driver should be synced to use
>     the same memory type to map a buffer. Otherwise, there will be
>     potential problem for incorrect memory data. But this will only impac=
t
>     the buggy guest alone.
>   * for live migration,
>     as QEMU will read all guest memory during live migration, page aliasi=
ng
>     could happen.
>     Current thinking is to disable live migration if a virtio device has
>     indicated its noncoherent state.
>     As a follow-up, we can discuss other solutions. e.g.
>     (a) switching back to coherent path before starting live migration.

both guest/host switching to coherent or host-only?

host-only certainly is problematic if guest is still using non-coherent.

on the other hand I'm not sure whether the host/guest gfx stack is
capable of switching between coherent and non-coherent path in-fly
when the buffer is right being rendered.

>     (b) read/write of guest memory with clflush during live migration.

write is irrelevant as it's only done in the resume path where the
guest is not running.

>=20
> Implementation Consideration
> =3D=3D=3D
> There is a previous series [1] from google to serve the same purpose to
> let KVM be aware of virtio GPU's noncoherent DMA status. That series
> requires a new memslot flag, and special memslots in user space.
>=20
> We don't choose to use memslot flag to request honoring guest memory
> type.

memslot flag has the potential to restrict the impact e.g. when using
clflush-before-read in migration? Of course the implication is to
honor guest type only for the selected slot in KVM instead of applying
to the entire guest memory as in previous series (which selects this
way because vmx_get_mt_mask() is in perf-critical path hence not
good to check memslot flag?)

> Instead we hope to make the honoring request to be explicit (not tied to =
a
> memslot flag). This is because once guest memory type is honored, not onl=
y
> memory used by guest virtio device, but all guest memory is facing page
> aliasing issue potentially. KVM needs a generic solution to take care of
> page aliasing issue rather than counting on memory type of a special
> memslot being aligned in host and guest.
> (we can discuss what a generic solution to handle page aliasing issue wil=
l
> look like in later follow-up series).
>=20
> On the other hand, we choose to introduce a KVM virtio device rather than
> just provide an ioctl to wrap kvm_arch_[un]register_noncoherent_dma()
> directly, which is based on considerations that

I wonder it's over-engineered for the purpose.

why not just introducing a KVM_CAP and allowing the VMM to enable?
KVM doesn't need to know the exact source of requiring it...