From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Christoph Egger <chegger@amazon.de>,
suravee.suthikulpanit@amd.com
Subject: Re: [PATCH v3] nested SVM: adjust guest handling of structure mappings
Date: Mon, 11 Nov 2013 13:16:25 +0000 [thread overview]
Message-ID: <5280D8A9.5060107@citrix.com> (raw)
In-Reply-To: <5280E13E0200007800101D43@nat28.tlf.novell.com>
On 11/11/13 12:53, Jan Beulich wrote:
> For one, nestedsvm_vmcb_map() error checking must not consist of using
> assertions: Global (permanent) mappings can fail, and hence failure
> needs to be dealt with properly. And non-global (transient) mappings
> can't fail anyway.
>
> And then the I/O port access bitmap handling was broken: It checked
> only to first of the accessed ports rather than each of them.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v3: Add error check to mapping operation in
> nsvm_vmcb_guest_intercepts_ioio() (pointed out by Andrew Cooper).
>
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -342,7 +342,7 @@ static int nsvm_vmrun_permissionmap(stru
> unsigned int i;
> enum hvm_copy_result ret;
> unsigned long *ns_viomap;
> - bool_t ioport_80, ioport_ed;
> + bool_t ioport_80 = 1, ioport_ed = 1;
>
> ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
>
> @@ -360,10 +360,12 @@ static int nsvm_vmrun_permissionmap(stru
> svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
>
> ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT, 0);
> - ASSERT(ns_viomap != NULL);
> - ioport_80 = test_bit(0x80, ns_viomap);
> - ioport_ed = test_bit(0xed, ns_viomap);
> - hvm_unmap_guest_frame(ns_viomap, 0);
> + if ( ns_viomap )
> + {
> + ioport_80 = test_bit(0x80, ns_viomap);
> + ioport_ed = test_bit(0xed, ns_viomap);
> + hvm_unmap_guest_frame(ns_viomap, 0);
> + }
>
> svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
>
> @@ -866,40 +868,45 @@ nsvm_vmcb_guest_intercepts_msr(unsigned
> static int
> nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1)
> {
> - unsigned long iopm_gfn = iopm_pa >> PAGE_SHIFT;
> - unsigned long *io_bitmap = NULL;
> + unsigned long gfn = iopm_pa >> PAGE_SHIFT;
> + unsigned long *io_bitmap;
> ioio_info_t ioinfo;
> uint16_t port;
> + unsigned int size;
> bool_t enabled;
> - unsigned long gfn = 0; /* gcc ... */
>
> ioinfo.bytes = exitinfo1;
> port = ioinfo.fields.port;
> + size = ioinfo.fields.sz32 ? 4 : ioinfo.fields.sz16 ? 2 : 1;
>
> - switch (port) {
> - case 0 ... 32767: /* first 4KB page */
> - gfn = iopm_gfn;
> + switch ( port )
> + {
> + case 0 ... 8 * PAGE_SIZE - 1: /* first 4KB page */
> break;
> - case 32768 ... 65535: /* second 4KB page */
> - port -= 32768;
> - gfn = iopm_gfn + 1;
> + case 8 * PAGE_SIZE ... 2 * 8 * PAGE_SIZE - 1: /* second 4KB page */
> + port -= 8 * PAGE_SIZE;
> + ++gfn;
> break;
> default:
> BUG();
> break;
> }
>
> - io_bitmap = hvm_map_guest_frame_ro(gfn, 0);
> - if (io_bitmap == NULL) {
> - gdprintk(XENLOG_ERR,
> - "IOIO intercept: mapping of permission map failed\n");
> - return NESTEDHVM_VMEXIT_ERROR;
> + for ( io_bitmap = hvm_map_guest_frame_ro(gfn, 0); ; )
> + {
> + enabled = io_bitmap && test_bit(port, io_bitmap);
> + if ( !enabled || !--size )
> + break;
> + if ( unlikely(++port == 8 * PAGE_SIZE) )
> + {
> + hvm_unmap_guest_frame(io_bitmap, 0);
> + io_bitmap = hvm_map_guest_frame_ro(++gfn, 0);
> + port -= 8 * PAGE_SIZE;
> + }
> }
Ok - this safe now, but I don't understand the reasoning for introducing
this loop?
The ioio exit value gives us a single port, and the size of access on
that specific port.
The switch statement tells us exactly which gfn the relevant bit refers
to, surely a single hvm_map_guest_frame_ro() is sufficient?
~Andrew
> -
> - enabled = test_bit(port, io_bitmap);
> hvm_unmap_guest_frame(io_bitmap, 0);
>
> - if (!enabled)
> + if ( !enabled )
> return NESTEDHVM_VMEXIT_HOST;
>
> return NESTEDHVM_VMEXIT_INJECT;
> @@ -966,8 +973,8 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
> switch (exitcode) {
> case VMEXIT_MSR:
> ASSERT(regs != NULL);
> - nestedsvm_vmcb_map(v, nv->nv_vvmcxaddr);
> - ASSERT(nv->nv_vvmcx != NULL);
> + if ( !nestedsvm_vmcb_map(v, nv->nv_vvmcxaddr) )
> + break;
> ns_vmcb = nv->nv_vvmcx;
> vmexits = nsvm_vmcb_guest_intercepts_msr(svm->ns_cached_msrpm,
> regs->ecx, ns_vmcb->exitinfo1 != 0);
> @@ -975,8 +982,8 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
> return 0;
> break;
> case VMEXIT_IOIO:
> - nestedsvm_vmcb_map(v, nv->nv_vvmcxaddr);
> - ASSERT(nv->nv_vvmcx != NULL);
> + if ( !nestedsvm_vmcb_map(v, nv->nv_vvmcxaddr) )
> + break;
> ns_vmcb = nv->nv_vvmcx;
> vmexits = nsvm_vmcb_guest_intercepts_ioio(ns_vmcb->_iopm_base_pa,
> ns_vmcb->exitinfo1);
>
>
next prev parent reply other threads:[~2013-11-11 13:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 8:33 [PATCH] nested SVM: adjust guest handling of structure mappings Jan Beulich
2013-11-11 11:07 ` [PATCH v2] " Jan Beulich
2013-11-11 11:25 ` Andrew Cooper
2013-11-11 12:29 ` Jan Beulich
2013-11-11 12:53 ` [PATCH v3] " Jan Beulich
2013-11-11 13:16 ` Andrew Cooper [this message]
2013-11-11 13:35 ` Jan Beulich
2013-11-11 14:40 ` Andrew Cooper
2013-11-11 13:22 ` Egger, Christoph
2013-11-12 3:57 ` Suravee Suthikulpanit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5280D8A9.5060107@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=chegger@amazon.de \
--cc=suravee.suthikulpanit@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).