From: Jan Kiszka <jan.kiszka@web.de>
To: Ed Swierk <eswierk@aristanetworks.com>
Cc: kvm@vger.kernel.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH] Xen PV-on-HVM guest support (v2)
Date: Thu, 15 Oct 2009 09:27:53 +0200 [thread overview]
Message-ID: <4AD6CEF9.7090301@web.de> (raw)
In-Reply-To: <1255585318.12773.14.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 5445 bytes --]
Ed Swierk wrote:
> Support for Xen PV-on-HVM guests can be implemented almost entirely in
> userspace, except for handling one annoying MSR that maps a Xen
> hypercall blob into guest address space.
>
> A generic mechanism to delegate MSR writes to userspace seems overkill
> and risks encouraging similar MSR abuse in the future. Thus this patch
> adds special support for the Xen HVM MSR.
>
> I implemented a new ioctl, KVM_XEN_HVM_CONFIG, that lets userspace tell
> KVM which MSR the guest will write to, as well as the starting address
> and size of the hypercall blobs (one each for 32-bit and 64-bit) that
> userspace has loaded from files. When the guest writes to the MSR, KVM
> copies one page of the blob from userspace to the guest.
>
> I've tested this patch with a hacked-up version of Gerd's userspace
> code, booting a number of guests (CentOS 5.3 i386 and x86_64, and
> FreeBSD 8.0-RC1 amd64) and exercising PV network and block devices.
>
> v2: fix ioctl struct padding; renumber CAP and ioctl constants; check
> kvm_write_guest() return value; change printks to KERN_DEBUG (I think
> they're worth keeping for debugging userspace)
I disagree /wrt the print in the IOCTL path (missing configuration can
also be reported on access), and the guest triggered path at least
requires a pr_debug conversion. Looks fine to me otherwise.
Jan
>
> Signed-off-by: Ed Swierk <eswierk@aristanetworks.com>
>
> ---
> Index: kvm-kmod/include/asm-x86/kvm.h
> ===================================================================
> --- kvm-kmod.orig/include/asm-x86/kvm.h
> +++ kvm-kmod/include/asm-x86/kvm.h
> @@ -59,6 +59,7 @@
> #define __KVM_HAVE_MSIX
> #define __KVM_HAVE_MCE
> #define __KVM_HAVE_PIT_STATE2
> +#define __KVM_HAVE_XEN_HVM
>
> /* Architectural interrupt line count. */
> #define KVM_NR_INTERRUPTS 256
> Index: kvm-kmod/include/linux/kvm.h
> ===================================================================
> --- kvm-kmod.orig/include/linux/kvm.h
> +++ kvm-kmod/include/linux/kvm.h
> @@ -476,6 +476,9 @@ struct kvm_ioeventfd {
> #endif
> #define KVM_CAP_IOEVENTFD 36
> #define KVM_CAP_SET_IDENTITY_MAP_ADDR 37
> +#ifdef __KVM_HAVE_XEN_HVM
> +#define KVM_CAP_XEN_HVM 38
> +#endif
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> @@ -528,6 +531,15 @@ struct kvm_x86_mce {
> };
> #endif
>
> +#ifdef KVM_CAP_XEN_HVM
> +struct kvm_xen_hvm_config {
> + __u32 msr;
> + __u8 pad[2];
> + __u8 blob_size[2];
> + __u64 blob_addr[2];
> +};
> +#endif
> +
> #define KVM_IRQFD_FLAG_DEASSIGN (1 << 0)
>
> struct kvm_irqfd {
> @@ -586,6 +598,7 @@ struct kvm_irqfd {
> #define KVM_CREATE_PIT2 _IOW(KVMIO, 0x77, struct kvm_pit_config)
> #define KVM_SET_BOOT_CPU_ID _IO(KVMIO, 0x78)
> #define KVM_IOEVENTFD _IOW(KVMIO, 0x79, struct kvm_ioeventfd)
> +#define KVM_XEN_HVM_CONFIG _IOW(KVMIO, 0x7a, struct kvm_xen_hvm_config)
>
> /*
> * ioctls for vcpu fds
> Index: kvm-kmod/include/linux/kvm_host.h
> ===================================================================
> --- kvm-kmod.orig/include/linux/kvm_host.h
> +++ kvm-kmod/include/linux/kvm_host.h
> @@ -236,6 +236,10 @@ struct kvm {
> unsigned long mmu_notifier_seq;
> long mmu_notifier_count;
> #endif
> +
> +#ifdef KVM_CAP_XEN_HVM
> + struct kvm_xen_hvm_config xen_hvm_config;
> +#endif
> };
>
> /* The guest did something we don't support. */
> Index: kvm-kmod/x86/x86.c
> ===================================================================
> --- kvm-kmod.orig/x86/x86.c
> +++ kvm-kmod/x86/x86.c
> @@ -875,6 +875,35 @@ static int set_msr_mce(struct kvm_vcpu *
> return 0;
> }
>
> +#ifdef KVM_CAP_XEN_HVM
> +static int xen_hvm_config(struct kvm_vcpu *vcpu, u64 data)
> +{
> + int blob = !!(vcpu->arch.shadow_efer & EFER_LME);
> + u32 pnum = data & ~PAGE_MASK;
> + u64 paddr = data & PAGE_MASK;
> + u8 *page;
> + int r = 1;
> +
> + if (pnum >= vcpu->kvm->xen_hvm_config.blob_size[blob])
> + goto out;
> + page = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!page)
> + goto out;
> + if (copy_from_user(page, (u8 *)vcpu->kvm->xen_hvm_config.blob_addr[blob]
> + + pnum * PAGE_SIZE, PAGE_SIZE))
> + goto out_free;
> + if (kvm_write_guest(vcpu->kvm, paddr, page, PAGE_SIZE))
> + goto out_free;
> + printk(KERN_DEBUG "kvm: copied xen hvm blob %d page %d to 0x%llx\n",
> + blob, pnum, paddr);
> + r = 0;
> +out_free:
> + kfree(page);
> +out:
> + return r;
> +}
> +#endif
> +
> int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> {
> switch (msr) {
> @@ -990,6 +1019,10 @@ int kvm_set_msr_common(struct kvm_vcpu *
> "0x%x data 0x%llx\n", msr, data);
> break;
> default:
> +#ifdef KVM_CAP_XEN_HVM
> + if (msr && (msr == vcpu->kvm->xen_hvm_config.msr))
> + return xen_hvm_config(vcpu, data);
> +#endif
> if (!ignore_msrs) {
> pr_unimpl(vcpu, "unhandled wrmsr: 0x%x data %llx\n",
> msr, data);
> @@ -2453,6 +2486,17 @@ long kvm_arch_vm_ioctl(struct file *filp
> r = 0;
> break;
> }
> +#ifdef KVM_CAP_XEN_HVM
> + case KVM_XEN_HVM_CONFIG: {
> + r = -EFAULT;
> + if (copy_from_user(&kvm->xen_hvm_config, argp,
> + sizeof(struct kvm_xen_hvm_config)))
> + goto out;
> + printk(KERN_DEBUG "kvm: configured xen hvm\n");
> + r = 0;
> + break;
> + }
> +#endif
> default:
> ;
> }
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
prev parent reply other threads:[~2009-10-15 7:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 5:41 [PATCH] Xen PV-on-HVM guest support (v2) Ed Swierk
2009-10-15 7:09 ` Avi Kivity
2009-10-15 8:11 ` Gerd Hoffmann
2009-10-15 8:12 ` Avi Kivity
2009-10-15 7:27 ` Jan Kiszka [this message]
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=4AD6CEF9.7090301@web.de \
--to=jan.kiszka@web.de \
--cc=eswierk@aristanetworks.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.