[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH v5 11/13] ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Sergiy Kibrik <sergiy_kibrik@xxxxxxxx>
- Date: Mon, 5 Aug 2024 13:59:44 +0300
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Rs7a3c0/s4ohRRs/H44R8yUhVxmz3B4BO3u+mNif0g0=; b=WGxZZe+hwiBE+8QqeAtm8W+KGk1DlmPqS7+fhGT2TrxqX92EKwOAz2OnZ5dS3AUMAJ5jMCv89y7v/043Xb63LMn1pP1XcoerZoabdD3JIPaxkNiFmt11DWRFTwnsKAz9R7gYigi6xC6wlWzKcVNCUKmGkz2bu5/8uL75WcTIQdmm5gqFRb51cOpVRcFaWtI5yeguRuj5SJppRTnMMtuLo/WpA6qxrVSyskpoDa3g4se+RAbAGz0uoIraRCPqF2n52BEVhN/c2nPKnoyDMfxqOo+klQN1bJOhqV0CiLoDFyrr0PZPR/Wz8/KZl/HPhGf+3nXWc7Nv34F/gKBXb+v1Ww==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RSbvP6Jj+xhRTeoilSLFdW8d8zXPJrXRQ1BNvo9LqbF2LK5+pr6rPUTsz98OKfWlc5OQ9uthCxAFOPh+1W1TItQ1bwxJ9ttjFWmwJL0EXKkZDtA3Gs9yjX/KsF+A5R8JYAHre4BTzKC/crk3Vey5HrJA3mGy1Oase2qsZ3ZVsvISFdJzBadrH+F9OnwPd9x+7O8dC3JZXqDbJq9c1oi0EtLqjeJD2h1ZcarRejQJp9a/CL4GeFLUVLFjSebKH1f5DUolVFqr6l4q5A5lRRQHiOWhEZUz9rQHZ4+48rc36MsyVa1OccpNz179hLum9eVlQgswVb1cfC+g3cLvKB5yhQ==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Julien Grall <julien@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 05 Aug 2024 11:00:15 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
31.07.24 15:39, Jan Beulich:
[..]
---
changes in v5:
- introduce ARCH_IOREQ_COMPLETION option & put arch_vcpu_ioreq_completion()
under it
- description changed
I'm worried by this naming inconsistency: We also have
arch_ioreq_complete_mmio(),
and who know what else we'll gain. I think the Kconfig identifier wants to
equally
include VCPU.
sure, I'll make it ARCH_VCPU_IOREQ_COMPLETION
[..]
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -111,7 +111,17 @@ void ioreq_domain_init(struct domain *d);
int ioreq_server_dm_op(struct xen_dm_op *op, struct domain *d, bool
*const_op);
bool arch_ioreq_complete_mmio(void);
+
+#ifdef CONFIG_ARCH_IOREQ_COMPLETION
bool arch_vcpu_ioreq_completion(enum vio_completion completion);
+#else
+static inline bool arch_vcpu_ioreq_completion(enum vio_completion completion)
+{
+ ASSERT_UNREACHABLE();
+ return true;
+}
I understand this is how the Arm stub had it, but is "true" really appropriate
here? Looking at the sole vcpu_ioreq_handle_completion() call site in x86 code,
I'm inclined to say "false" would be better: We shouldn't resume a vCPU when
such an (internal) error has been encountered.
not just Arm stub, both x86 & Arm variants of
arch_vcpu_ioreq_completion() return true unconditionally, so there must
be a reason for this.
-Sergiy
|
