Difference in event channel implementation for Xen PV vs HVM guests
Roger Pau Monné
roger.pau at citrix.com
Tue Mar 19 17:23:36 UTC 2013
On 18/03/13 14:08, Justin T. Gibbs wrote:
> On Mar 18, 2013, at 6:35 AM, Roger Pau Monné <roger.pau at citrix.com> wrote:
>> While working on improving XENHVM (I've been looking at adding PV
>> timers), I've realized that the event channel implementation in PV vs
>> HVM mode differs greatly. Xen PV port uses sys/xen/evtchn/evtchn.c while
>> Xen HVM uses sys/dev/xenpci/evtchn.c, and the Xen HVM implementation is
>> greatly reduced (only contains the necessary functions to operate
>> To implement PV timers I need to expand the event channel interface for
>> XENHVM, and I was wondering why FreeBSD choose to have two different
>> implementations, the main difference between PV and HVM is the event
>> callback, but I guess this can be abstracted between the two different
>> implementations, and then everything else could be reused. Am I missing
>> something obvious?
>> Is there any known technical problem in modifying XENHVM to use the full
>> event channel implementation present in sys/xen/evtchn/evtchn.c that
>> prevented XENHVM from using it in the first place?
>> (Sorry if I've Cc'ed someone not related)
>> Thanks, Roger.
>> freebsd-virtualization at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"
> Hi Roger,
> I know of no reasons why XENHVM cannot use the full event channel
> interface. In fact, Spectra Logic implemented PV timers and a
> general cleanup of the HVM event channel interface. I haven't merged
> it back yet because I know the changes break PV and I haven't found
> time to clean up the PV code, merge the HVM and PV event channel
> systems, and move IPI/MSI delivery to event channels.
That sounds great, then FreeBSD will have a fully working PVHVM port.
> I've uploaded Spectra's changes here:
> The diffs file provides the history of the original checkins to our
> Perforce repository. The tar file includes all the files that have
> been modified and reflects our efforts to keep our code base in
> sync with stable/9. Apart from the PV issues outlined above, I
> would expect the code provided to just drop right in to stable/9.
Wow, this is a lot of work to keep in a closet, I will start by rebasing
those on top of HEAD, and probably try to split them into smaller
commits that make logical sense.
> Unfortunately, Xen support is not a current priority for Spectra
> so I don't have a lot of day job time to focus on getting this code back
> into FreeBSD. However, if this code looks like it would suite
> your needs, and you have resources for testing i386/PV, I'd be happy
> to collaborate with you and will make the time to help get this
Definitely, you guys did already a lot of work, and it will a shame to
lose it, right now I got my plate quite full, but I expect to get on
with this in a couple of weeks.
More information about the freebsd-virtualization