Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Aug 2014 11:31:29 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-drivers@freebsd.org
Cc:        "freebsd-xen@freebsd.org" <freebsd-xen@freebsd.org>, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org>, Roger Pau =?iso-8859-1?q?Monn=E9?= <roger.pau@citrix.com>
Subject:   Re: Directly reserve an interrupt IDT entry for Hyper-V
Message-ID:  <201408201131.29399.jhb@freebsd.org>
In-Reply-To: <53F4A34A.4010807@citrix.com>
References:  <3defccd56bc0407c88bdda139b2462ac@BY1PR0301MB0902.namprd03.prod.outlook.com> <53F4A34A.4010807@citrix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, August 20, 2014 9:31:54 am Roger Pau Monn=E9 wrote:
> On 20/08/14 11:19, Wei Hu wrote:
> > Hello,
> >=20
> > Sending to Xen, drivers and virtualization mailing lists since this mig=
ht=20
be of interest to the folks on these aliases.
> >=20
> > I am working for Microsoft to improve the performance of FreeBSD runnin=
g=20
on Hyper-V. Right now I am adding a feature in the vmbus driver which could=
=20
handle the host-guest channel communications on all vCPUs simultaneously. I=
n=20
order to achieve this, the hypervisor will send same interrupt concurrently=
 on=20
all the vCPUs. The traditional way on FreeBSD to set up interrupt handling =
for=20
devicse, such as calling bus_alloc_resource() to reserve an IRQ line, and t=
hen=20
calling bus_setup_intr() to create a vector, doesn't seem to work in this=20
case. It seems if the interrupt is routed via legacy IRQ, it can only be=20
active on one vCPU at a time. In order to allow the same interrupt to be=20
handled on all vCPUs concurrently, all I need is an IDT entry, not an IRQ=20
line.
> >=20
> > I checked current FreeBSD code. It looks to me Xen directly uses the=20
vector number IDT_EVTCHN (0x93) to achieve the same purpose. I am proposing=
=20
both Xen and Hyper-V share this same vector. Following is a little bit deta=
il=20
of my proposal for the changes in the current kernel.
> >=20
> >=20
> > 1.       In machdep.c:
> >=20
> >  #ifdef XENHVM
> >=20
> >         setidt(IDT_EVTCHN, &IDTVEC(xen_intr_upcall), SDT_SYSIGT, SEL_UP=
L,=20
0);
> >=20
> > #else
> >=20
> >         setidt(IDT_EVTCHN, &IDTVEC(hv_vmbus_intr), SDT_SYSIGT, SEL_UPL,=
=20
0);
> >=20
> > #endif
> >=20
> > 2.       Apic_vector.S
> >=20
> > Add IDTVEC(hv_vmbus_intr) to call Hyper-V vmbus interrupt service routi=
ne.
> >=20
> > Any  thoughts, objections and feedbacks are all welcome.
>=20
> Hello,
>=20
> I don't think using the same IDT vector is the right approach, I would
> just pick a different IDT vector and use that for Hyper-V. Using the
> same IDT vector (like your suggestion above) would prevent shipping a
> kernel with with both Hyper-V and Xen support (like it's done now in
> GENERIC).
>=20
> Roger.

Hmm, can't you make this a runtime check to only call setidt() if you detec=
t=20
you are under the appropriate hypervisor?

Also, bhyve currently has a hackish way of requesting a free IDT slot. =20
Perhaps it would be best if I added little API to reserve an IDT slot assum=
ing=20
that callers could accept a dynamic IDT vector rather than a static one.

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408201131.29399.jhb>