Re: [Xen-devel] [PATCH] arm/monitor vm-events: Implement guest-request support

[Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>]

On 2/19/2016 7:15 PM, Jan Beulich wrote:
> > > > On 19.02.16 at 17:25, <czuzu@xxxxxxxxxxxxxxx> wrote:
> > On 2/19/2016 4:26 PM, Jan Beulich wrote:
> > > > > > On 18.02.16 at 20:35, <czuzu@xxxxxxxxxxxxxxx> 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?
> > Are you referring to "xen/arch/arm/hvm.c"? If so, I did not introduce
> > that file, it was already there, all I did is add handling of
> > HVMOP_guest_request_vm_event to ARM-side's already existing do_hvm_op :).
> No, I'm referring to your initial attempt to create arch/arm/hvm/...
I don't understand. Have I done that again with this patch?

> > On the "HVM-ish" note, is there some incompatibility between ARM and the
> > concept of HVM?
> ARM guests are neither PV nor HVM right now, but somewhere in
> the middle (PVHv2 may come closest).
I did not know that, but the fact that there is already "hvm-like" code 
written for ARM didn't hint me towards that fact either :)
I'm aware that I'm far from familiar with the codebase right now, I'm 
browsing more of the code these days and taking notes to try and 
understand in depth at least the parts I'm sending contributions for.
I've already got some questions I want to post to the mailing list soon, 
*including* exactly how the distinction between the guest-types comes 
into play w/ the vm-events code.
Specifically, I'm talking for example about the following piece of code 
from the X86 arch_monitor_get_capabilities:
    /*
     * At the moment only Intel HVM domains are supported. However, event
     * delivery could be extended to AMD and PV domains.
     */
    if ( !is_hvm_domain(d) || !cpu_has_vmx )
        return capabilities;

== "However, event delivery could be extended to AMD and PV domains".
This comment begs for questions like:
* what would be necessary to extend support to PV domains?
* can we really do this operation without hardware assisted 
virtualization whatsoever? If not, how much can we do without that?
* what about pvh?

Since I have other questions like the above and I'll probably have more 
while I'm trying to get a better picture of the code, would it be ok if 
we defer addressing these issues to then?
> > > > --- a/xen/include/asm-x86/domain.h
> > > > +++ b/xen/include/asm-x86/domain.h
> > > > @@ -376,17 +376,15 @@ struct arch_domain
> > > >        unsigned long *pirq_eoi_map;
> > > >        unsigned long pirq_eoi_map_mfn;
> > > >    
> > > > -    /* Monitor options */
> > > > +    /* Arch-specific monitor options */
> > > >        struct {
> > > > -        unsigned int write_ctrlreg_enabled       : 4;
> > > > -        unsigned int write_ctrlreg_sync          : 4;
> > > > -        unsigned int write_ctrlreg_onchangeonly  : 4;
> > > > -        unsigned int mov_to_msr_enabled          : 1;
> > > > -        unsigned int mov_to_msr_extended         : 1;
> > > > -        unsigned int singlestep_enabled          : 1;
> > > > -        unsigned int software_breakpoint_enabled : 1;
> > > > -        unsigned int guest_request_enabled       : 1;
> > > > -        unsigned int guest_request_sync          : 1;
> > > > +        uint16_t write_ctrlreg_enabled       : 4;
> > > > +        uint16_t write_ctrlreg_sync          : 4;
> > > > +        uint16_t write_ctrlreg_onchangeonly  : 4;
> > > > +        uint16_t mov_to_msr_enabled          : 1;
> > > > +        uint16_t mov_to_msr_extended         : 1;
> > > > +        uint16_t singlestep_enabled          : 1;
> > > > +        uint16_t software_breakpoint_enabled : 1;
> > > >        } monitor;
> > > What is this type change supposed to achieve in general, and in
> > > particular in the context of this patch?
> > Some time before this patch there was a discussion I had w/ ARM
> > maintainer Ian Campbell who made the suggestion to try and move parts of
> > the monitor vm-events code to the common-side.
> > (you can find that discussion here:
> > https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg54139.html).
> > In short, the reason for his suggestion was that that previous attempt
> > of mine to add guest-request support for ARM highlighted code
> > duplication between X86 and ARM if I were to leave the monitor vm-events
> > code as it was (that is, completely arch-specific). In an effort to
> > avoid that, I first submitted a 7 patch-series which tried to move as
> > much as possible to the common-side.
> > "As much as possible" meant guest-request, ctrl-reg write, single-step
> > and software breakpoints, all moved to the common-side. That also meant
> > introducing some Kconfigs to selectively activate some parts of that
> > now-common code, since not all of it was used on ARM at that moment.
> > Although conceptually that code could have remained on the common-side,
> > Tamas pointed out that we could get rid of the Kconfigs (which in his
> > opinion bloated the code) by only moving at the moment what is
> > implemented on both X86 and ARM. As for the rest, he noted that when I
> > add implementations for the other monitor vm-events on ARM as well, I
> > could move that to common as well. The above is a result of that -
> > guest-request is implemented on both X86 and ARM with this patch, hence
> > I also moved it to common.
> I agree there are two fields being removed. But the question was
> why you also change the type of the other fields.
It made sense because:
* we don't need 32-bits to store that data anymore
* as implementations are laid out for ARM also, more of those bits will 
get moved to common, so even less bits will be needed
> > > > --- a/xen/include/asm-x86/hvm/event.h
> > > > +++ b/xen/include/asm-x86/hvm/event.h
> > > > @@ -1,5 +1,9 @@
> > > >    /*
> > > > - * event.h: Hardware virtual machine assist events.
> > > > + * include/asm-x86/hvm/event.h
> > > > + *
> > > > + * Arch-specific hardware virtual machine event abstractions.
> > > > + *
> > > > + * Copyright (c) 2016, Bitdefender S.R.L.
> > > Is this true? Namely, was _all_ of the code here written by people
> > > on your company, including what may have got moved here from
> > > elsewhere?
> > My bad. Removing that line would be satisfactory, yes?
> To me, yes.
>
> Jan
Noted.

Corneliu.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel