lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Mar 2010 10:56:42 +0800
From:	Sheng Yang <>
To:	Stefano Stabellini <>,
	Ian Campbell <>,
	Jeremy Fitzhardinge <>
Cc:	Jeremy Fitzhardinge <>,
	"xen-devel" <>,
	"" <>,
	Ian Pratt <>,
	Keir Fraser <>,
	Ingo Molnar <>,
	Konrad Rzeszutek Wilk <>
Subject: Re: [Xen-devel] [PATCH 7/7] xen: Enable event channel of PV extension of HVM

On Tuesday 09 March 2010 18:22:31 Stefano Stabellini wrote:
> On Tue, 9 Mar 2010, Ian Campbell wrote:
> > On Tue, 2010-03-09 at 07:00 +0000, Jeremy Fitzhardinge wrote:
> > > On 03/08/2010 05:53 PM, Sheng Yang wrote:
> > > > On Tuesday 09 March 2010 01:10:56 Stefano Stabellini wrote:
> > > >> I think that mapping interrupts into VIRQs is a bad idea: you should
> > > >> map interrupts into pirqs instead, the code exists already on the
> > > >> kernel side so we don't need to do any (ugly) change ther.
> > > >
> > > > The code existed in the pv_ops dom0 side, but not in the upstream
> > > > Linux. The latter is our target. We want this work to be accepted by
> > > > upstream Linux soon.
> > >
> > >    2. It has significant overlaps with the current xen.git development
> > >       which is also targeted for upstream.  There's no point in
> > > creating an unnecessary duplicate mechanism when the infrastructure
> > > will be in place anyway.
> >
> > There's also nothing stopping us from upstreaming portions of the "dom0"
> > patchset ahead of full dom0 support if it is useful for some domU
> > feature.
> Indeed.
> You just need the pirq mappings and few other things, it shouldn't be
> too hard.
> At this point I am going to do that myself after this patch series is
> completed.
I think we can leave the controversial thing later. At least, we want a 
framework for PV extension of HVM. We can work together to determine what is 
the better way for evtchn, as well as porting pirqs. (And the later MSI work 
may also depends on it)

But I think the former 6 patches can be taken as the base. It won't overlapped 
with others. And PV clocksource is definitely important for HVM guest. We 
would like to get the first 6 ones checked in Linux upstream first, then we 
can work on others. And it would the work easier for us later.

So Jeremy, how about a even more simplified version only contained framework 
and pv clocksource? I think it's pretty elegant and solid first step into 
Linux upstream.

If you agree, I would send the updated patchset soon, only framework and pv 

Yang, Sheng
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists