public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: "Zhang, Xiantao" <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	kvm-ppc-devel
	<kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH] Split kvm_vcpu to support new archs.
Date: Thu, 18 Oct 2007 15:01:42 -0500	[thread overview]
Message-ID: <1192737702.21205.17.camel@basalt> (raw)
In-Reply-To: <42DFA526FC41B1429CE7279EF83C6BDC809A6A-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>

On Thu, 2007-10-18 at 15:34 +0800, Zhang, Xiantao wrote:
> Hi Avi,
> According to your and community's suggestions, I changed the kvm_vcpu
> structure to two parts. To avoid the much intrusive into current code,
> one is common part which is defined as a macro, and the other one is
> arch-specific part.  
> In addition, I have a suggestion to re-organize the head files, such as
> kvm.h and x86.h.  IMO, kvm.h is changed to kvm_comm.h, and only includes
> common code for all archs.Then x86.h will be changed to kvm-x86.h, and
> linked as kvm.h at compile time.  So, other archs also defines its
> kvm-xx.h to accommodate its arch-specific structures.  What's your ideas
> ?(This idea doesn't include in this patch.)

First of all let me say that I hate cpp macros. What is the problem with
embedding an architecture-specific sub-structure, i.e.
        struct kvm_vcpu {
                ...
                struct arch_kvm_vcpu arch_vcpu;
        };

This has a nice software engineering property too: common code will have
to explicitly dereference "arch_vcpu", which in the best case wouldn't
even compile, but even in the worst case is at least a visual red flag.
The way you're using macros, there is nothing obviously wrong about
"vcpu->host_tsc" in shared code.

One more comment below.

> >From 34cebd3a3fc0afba4df511219912bc3277e2a8c7 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Thu, 18 Oct 2007 12:51:02 +0800
> Subject: [PATCH] First step to split kvm_vcpu. Currently, we just use an
> macro to define the common fields in kvm_vcpu for all archs, and all
> archs need to define its own kvm_vcpu struct.
> Signed-off-by: Zhang Xiantao <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/kvm/ioapic.c      |    2 +
>  drivers/kvm/irq.c         |    1 +
>  drivers/kvm/kvm.h         |  166
> +++++++-------------------------------------
>  drivers/kvm/kvm_main.c    |    4 +-
>  drivers/kvm/lapic.c       |    2 +
>  drivers/kvm/mmu.c         |    1 +
>  drivers/kvm/svm.c         |    2 +-
>  drivers/kvm/vmx.c         |    1 +
>  drivers/kvm/x86.h         |  128 ++++++++++++++++++++++++++++++++++
>  drivers/kvm/x86_emulate.c |    1 +
>  10 files changed, 166 insertions(+), 142 deletions(-)
...
> +#ifdef CONFIG_HAS_IOMEM
> +#define KVM_VCPU_MMIO \
> +	int mmio_needed;\
> +	int mmio_read_completed;\
> +	int mmio_is_write;\
> +	int mmio_size;\
> +	unsigned char mmio_data[8];\
>  	gpa_t mmio_phys_addr;
> -	gva_t mmio_fault_cr2;
> -	struct kvm_pio_request pio;
> -	void *pio_data;
> -	wait_queue_head_t wq;
> 
> -	int sigset_active;
> -	sigset_t sigset;
> +#else
> +#define KVM_VCPU_MMIO
> 
> -	struct kvm_stat stat;
> +#endif

...

> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index aab465d..9ff049c 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -2272,7 +2272,7 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
> *vcpu, struct kvm_run *kvm_run)
>  		if (r)
>  			goto out;
>  	}
> -
> +#if CONFIG_HAS_IOMEM
>  	if (vcpu->mmio_needed) {
>  		memcpy(vcpu->mmio_data, kvm_run->mmio.data, 8);
>  		vcpu->mmio_read_completed = 1;
> @@ -2287,7 +2287,7 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu
> *vcpu, struct kvm_run *kvm_run)
>  			goto out;
>  		}
>  	}
> -
> +#endif

It does not make sense to share kvm_vcpu_ioctl_run(). Just look at it.

FYI, "char mmio_data[8]" has alignment problems. PowerPC has
endian-reversed load/store instructions, and to use them target data
must be aligned.

Also, memcpy() doesn't work for big-endian systems with sub-word loads.
Imagine if I do a single-byte load: "memcpy(&gpr, mmio_data, 1)" would
set the MSB, but the byte should land in the LSB of the register.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

  parent reply	other threads:[~2007-10-18 20:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-18  7:34 [PATCH] Split kvm_vcpu to support new archs Zhang, Xiantao
     [not found] ` <42DFA526FC41B1429CE7279EF83C6BDC809A6A-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-10-18 14:22   ` Avi Kivity
2007-10-18 20:01   ` Hollis Blanchard [this message]
2007-10-18 21:04     ` Anthony Liguori
     [not found]       ` <4717CA4B.7040307-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-10-18 21:14         ` Hollis Blanchard
2007-10-18 21:31           ` Anthony Liguori
     [not found]             ` <4717D095.40708-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-10-18 21:43               ` [kvm-ppc-devel] " Hollis Blanchard
2007-10-18 22:04                 ` Anthony Liguori
     [not found]                   ` <4717D87E.5010000-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-10-19 17:16                     ` Hollis Blanchard
2007-10-19 13:34                 ` Carsten Otte
2007-10-21  6:40     ` Avi Kivity
     [not found]       ` <471AF450.9040202-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-22 19:18         ` Hollis Blanchard
2007-10-23 12:14           ` Carsten Otte
     [not found]             ` <471DE5B2.4030709-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-10-24 11:44               ` Zhang, Xiantao
2007-10-25  2:56           ` Jerone Young

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=1192737702.21205.17.camel@basalt \
    --to=hollisb-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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