From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corneliu ZUZU Subject: Re: [PATCH] arm/monitor vm-events: Implement guest-request support Date: Fri, 19 Feb 2016 18:35:20 +0200 Message-ID: <56C74448.1080709@bitdefender.com> References: <1455824116-13783-1-git-send-email-czuzu@bitdefender.com> <56C7341402000078000D427C@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1754149783338369140==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel , Jan Beulich Cc: Keir Fraser , Ian Campbell , Razvan Cojocaru , Andrew Cooper , Xen-devel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============1754149783338369140== Content-Type: multipart/alternative; boundary="------------080008040300010602060807" This is a multi-part message in MIME format. --------------080008040300010602060807 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/19/2016 6:02 PM, Tamas K Lengyel wrote: > > > On Fri, Feb 19, 2016 at 7:26 AM, Jan Beulich > wrote: > > >>> On 18.02.16 at 20:35, > wrote: > > --- > > MAINTAINERS | 1 + > > xen/arch/arm/hvm.c | 8 +++ > > xen/arch/x86/hvm/event.c | 116 > ++++++---------------------------------- > > xen/arch/x86/hvm/hvm.c | 1 + > > xen/arch/x86/monitor.c | 14 ----- > > xen/arch/x86/vm_event.c | 1 + > > xen/common/Makefile | 2 +- > > xen/common/hvm/Makefile | 3 +- > > xen/common/hvm/event.c | 96 > +++++++++++++++++++++++++++++++++ > > So here you _again_ try to introduce something HVM-ish for ARM. > Why? Why can't this code live in common/vm_event.c? > > > I too am wondering if this is the right way to architect this. It > would be better to move the guest-requested stuff into the generic > vm_event component as it doesn't seem to be HVM specific other then it > using an HVMOP hypercall to be triggered. > > Tamas > Oh, that. "xen/common/hvm/event.c". I too don't know if it's the right way, but Jan, please at least don't attribute the way the code already is to me, I did not architect it. And it's not human to expect doing everything perfectly in a single shot. If you're of the opinion that it should be in vm_event.c I will gladly try to put it there. Of course, that could also be done in another patch. Corneliu. --------------080008040300010602060807 Content-Type: text/html; charset=utf-8 Content-Length: 3626 Content-Transfer-Encoding: quoted-printable
On 2/19/2016 6:02 PM, Tamas K Lengyel wrote:


On Fri, Feb 19, 2016 at 7:26 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 18.02.16 at 20:35, <czuzu@bitdefender.com> wrote:
> ---
>=C2=A0 MAINTAINERS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A01 +
>=C2=A0 xen/arch/arm/hvm.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A08 +++
>=C2=A0 xen/arch/x86/hvm/event.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 116 ++++++----------------------------------
>=C2=A0 xen/arch/x86/hvm/hvm.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A01 +
>=C2=A0 xen/arch/x86/monitor.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 14 -----
>=C2=A0 xen/arch/x86/vm_event.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A01 +
>=C2=A0 xen/common/Makefile=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A02 +-
>=C2=A0 xen/common/hvm/Makefile=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A03 +-
>=C2=A0 xen/common/hvm/event.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 96 +++++++++++++++++++++++++++++++++

So here you _again_ try to introduce something HVM-ish for ARM.
Why=3F Why can't this code live in common/vm_event.c=3F

I too am wondering if this is the right way to architect this. It would be better to move the guest-requested stuff into the generic vm_event component as it doesn't seem to be HVM specific other then it using an HVMOP hypercall to be triggered.

Tamas


Oh, that. "xen/common/hvm/event.c". I too don't know if it's the right way, but Jan, please at least don't attribute the way the code already is to me, I did not architect it.
And it's not human to expect doing everything perfectly in a single shot. If you're of the opinion that it should be in vm_event.c I will gladly try to put it there. Of course, that
could also be done in another patch.

Corneliu.
 --------------080008040300010602060807-- --===============1754149783338369140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1754149783338369140==--