[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>
  • Date: Fri, 19 Feb 2016 20:01:41 +0200
  • Cc: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Fri, 19 Feb 2016 18:01:52 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=Yu6zjS8xA7bMga6AchLbYabUPEF0caqVWus73fiENdQWUJq0gmzbAr3InH3XTTk2410m1noZcXD6TJfv6IfBEtDtQHgUdK2LxfegW1HugjCQ4Ug0KGuCoL4QR6rR2J9roJ7TpFTo4Sosb0gd5XSCi5AelLfAiciWb3vQ0Pjgs/30u6hcibtNdj87fTFKrn0Nz1TIQz/k3yGfE/v+1rqg7kKcgwtMymUirgvDWb0pGmOgjLMHKHKjqoobLbgGJc4CuwrUD5KYlSMcBJKCq9x2Oc5Q6LGAPZHF0t6XasFwEe8SqhCsHKT9SlCMz3LizhdK0umXVn5Vkuod0RLJ/2rmHQ==; h=Received:Received:Received:Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.