[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] xen/vioapic: add support for the extended destination ID field
- To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 24 Jan 2022 14:20:47 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=SJri2JJBNhtwi/mcM/e5cPT4Xx1ZW0/ELNEn+lzpNeU=; b=HBtzw6HV3CwabHFv/GDLvTBcky63F8MRCJwefFh+uFUfAxwxTTNpXtSjG709nzobMb8zQmx8YVxdf7CGkuxQWM5y+7yd08LDkdKbsXShaQPmiNhMr8+4jxpEyhQyvwElY3dq7XxBB+57sA6Op++MqGyjgIopC5cYGYTETQvjGWTOMr2OfLnLJBEzBHrp551ZbK6vAiLNSmUmhu1hHtvtS6gsBXs+z4Ucvm2YspTq3gtf31psAvhUejFWQwkQr9Xnn+sGPqk+ZmUzHy9YRwaZ3d9OjPPGkk1xQzQXVpMGr2/5/cgBUpjLuU4Q6y6kEQAcetdrhHllytlf4GX5K2MbDw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GFSIiOIANY+i7q3M26OLNdSRGCvhGQMlZc/+lKs5GI31dc3j5tFTJbeKFa1vbsi50Qg0aXSshlHdnHH5oInJjghAvn3sJD543keLfH9NuQxrVwPBAi3kkHhmNfMj7GHTQjfe8o52uhHfbyNCkzBe1A/5dx3reh73Ldo1YixfK6M8rroJnfFyWelVbKL5ol50qo8xI+ZiqU3auR+ke5OpjonozN9Heom4tiydvfvtTJ+D/2nZfDWomE+9ixMJuWDAB59SFuWnvKWdJEhDAdzrVWHEyyFLvZoIcuvO2syKfjIQonOTLjPKoPv9RzZIi5YzKmB2ZWuNynt6e8l03oX7ig==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 24 Jan 2022 13:21:12 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 20.01.2022 16:23, Roger Pau Monne wrote:
> Such field uses bits 55:48, but for the purposes the register will be
> used use bits 55:49 instead. Bit 48 is used to signal an RTE entry is
> in remappable format which is not supported by the vIO-APIC.
Neither here nor in the cover letter you point at a formal specification
of this mode of operation. What I'm aware of are vague indications of
this mode's existence in some of Intel's chipset data sheets. Yet that
leaves open, for example, whether indeed bit 48 cannot be used here.
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -412,7 +412,8 @@ static void ioapic_inj_irq(
>
> static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin)
> {
> - uint16_t dest = vioapic->redirtbl[pin].fields.dest_id;
> + uint16_t dest = vioapic->redirtbl[pin].fields.dest_id |
> + (vioapic->redirtbl[pin].fields.ext_dest_id << 8);
What if an existing guest has been writing non-zero in these bits? Can
you really use them here without any further indication by the guest?
Jan
|
