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 v2] nested SVM: adjust guest handling of structure mappings
Date: Mon, 11 Nov 2013 11:25:18 +0000 [thread overview]
Message-ID: <5280BE9E.1060209@citrix.com> (raw)
In-Reply-To: <5280C8830200007800101BCD@nat28.tlf.novell.com>
[-- Attachment #1.1: Type: text/plain, Size: 5052 bytes --]
On 11/11/13 11:07, 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>
> ---
> v2: Refine the change to nsvm_vmrun_permissionmap() -
> hvm_map_guest_frame_*() can return NULL for reasons other than
> map_domain_page_global() doing so (pointed out by Andrew Cooper).
> That leaves the function broken though (it ought to handle the
> shared/paged out cases in an appropriate way).
>
> --- 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);
> + }
Should we not bail on an error here, similar to the failure of
hvm_copy_from_guest just out of context above?
>
> 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); ; )
This needs further checking for NULL.
~Andrew
> + {
> + enabled = 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;
> + }
> }
> -
> - 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);
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 5889 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-11-11 11:25 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 [this message]
2013-11-11 12:29 ` Jan Beulich
2013-11-11 12:53 ` [PATCH v3] " Jan Beulich
2013-11-11 13:16 ` Andrew Cooper
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=5280BE9E.1060209@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).