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

Re: [XEN PATCH v3] x86/monitor: Add new monitor event to catch I/O instructions


  • To: Dmitry Isaykin <isaikin-dmitry@xxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 20 Mar 2023 12:01:34 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7euEy04DWu7SHJGAnJXvrE74ZCROgb3Jl6BV4SgQmyE=; b=EOvFfMfAYhuLUFUwyTlgppkd+i6/H9rfA6MW7cUNRSmn04K9RtVSm4gT/IB/8OBkh0upuFoWNVv20ufGS6K+HqcIdAn5KDpvmf5vWg6Gp66dKzShdLy6hAGcDoHhQFo1Xs/f5wXbEWrmXXcuwjtGciAjchzJ/x3czTjdIBekrKfPBmWuQNJtJRAm4jd5AwLo9ZlPVD5kLJQLXYQhVREgtgkzJeHLSnpQZssf1qtUkS9VUpnDz1A3VmGBAlK0bxzuvsqQJp++qRrrXD6aSPTO2Qyz47IU9aIT3N3NfSoySTlAdV6tdYSAF00Nss7Ngl96+8ABnknsX6epC3Yohp5mgg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CNNGcXlpiSCh9GDeHXzcU6sbCf8ogufd8ldLwIhm7dea18VKouer9JAwjFsBcb+nki6Lv3la1sgKklR4i7zwhkfuJ1GDHFBfmL7HHKGiIJyaW7VkzzJO0tnaXxEuWIGAvhNQ1V0G1dZThkvF+eX1kIzrtstpYdgPr2WcNHSRgDFt9Q03sDToY/CCTpBU1D4JTyLAl+MajliOQRPkuj2imgHAKC8XTxvZqfqS9xQzK8PR1VgfHyncGrNiw+xvjXm9w7OEFWOKg8hc49unOOyV+CbTvWnoS+ETAYxodI88boynYQyA1GOx8XN6os6tnTFH9YegsMdhAatH7B2+Yd9nAQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Anton Belousov <abelousov@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 20 Mar 2023 11:01:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17.03.2023 13:01, Dmitry Isaykin wrote:
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -346,6 +346,27 @@ int hvm_monitor_vmexit(unsigned long exit_reason,
>      return monitor_traps(curr, ad->monitor.vmexit_sync, &req);
>  }
>  
> +int hvm_monitor_io(uint16_t port, unsigned int bytes,

Please avoid the use of fixed-width types where not really necessary. See
./CODING_STYLE.

> +                   int dir, bool string_ins)

"ins" is an ambiguous abbreviation, even more so when anyway talking about
x86'es I/O instructions. You might consider simply omitting the suffix, or
alternatively I'd like to ask for "insn" (my preference) or "instr".

> +{
> +    struct vcpu *curr = current;
> +    struct arch_domain *ad = &curr->domain->arch;
> +    vm_event_request_t req = {};
> +
> +    if ( !ad->monitor.io_enabled )
> +        return 0;
> +
> +    req.reason = VM_EVENT_REASON_IO_INSTRUCTION;
> +    req.u.io.data_size = bytes;
> +    req.u.io.port = port;
> +    req.u.io.dir = dir;
> +    req.u.io.string_ins = string_ins;

Having these be the variable's initializer would probably be more in line
with what we do elsewhere, including in many cases right in this same
source file (yet sadly it's not really consistent).

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4560,7 +4560,24 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>          break;
>  
>      case EXIT_REASON_IO_INSTRUCTION:
> +    {
> +        uint16_t port;
> +        int bytes, dir;

Since you move it, "bytes" wants to be "unsigned int" (together with "port").
At which point "dir" ...

> +        bool string_ins;
> +        int rc;

... can share a declaration with "rc".

>          __vmread(EXIT_QUALIFICATION, &exit_qualification);
> +
> +        port = (exit_qualification >> 16) & 0xFFFF;
> +        bytes = (exit_qualification & 0x07) + 1;
> +        dir = (exit_qualification & 0x08) ? IOREQ_READ : IOREQ_WRITE;
> +        string_ins = (exit_qualification & 0x10);
> +        rc = hvm_monitor_io(port, bytes, dir, string_ins);
> +        if ( rc < 0 )
> +            goto exit_and_crash;
> +        if ( rc )
> +            break;
> +
>          if ( exit_qualification & 0x10 )

Please either use the new local variable here then as well, or omit it
in favor of using the same expression in the other function call.

> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -160,6 +160,8 @@
>  #define VM_EVENT_REASON_EMUL_UNIMPLEMENTED      14
>  /* VMEXIT */
>  #define VM_EVENT_REASON_VMEXIT                  15
> +/* IN/OUT Instruction executed */
> +#define VM_EVENT_REASON_IO_INSTRUCTION          16
>  
>  /* Supported values for the vm_event_write_ctrlreg index. */
>  #define VM_EVENT_X86_CR0    0
> @@ -388,6 +390,13 @@ struct vm_event_vmexit {
>      } arch;
>  };
>  
> +struct vm_event_io {
> +    uint32_t data_size;
> +    uint16_t port;
> +    uint8_t  dir; /* IOREQ_READ or IOREQ_WRITE */

Are you actually sure you want to tie the vm-event interface to the ioreq
one (this is also a question to you, Tamas)? It would look slightly better
to me if this was a simple boolean named after its purpose (e.g. "write"
or "out" when it's meant to be set for OUT / OUTS and clear for IN / INS).

Jan



 


Rackspace

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