From: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
"Zhang,
Xiantao" <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
Date: Thu, 08 Nov 2007 14:18:27 -0600 [thread overview]
Message-ID: <1194553107.22879.29.camel@basalt> (raw)
In-Reply-To: <473313D8.4010604-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
On Thu, 2007-11-08 at 14:49 +0100, Carsten Otte wrote:
> Zhang, Xiantao wrote:
> > +void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu);
> > +void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu);
> > +void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
> > +void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
> > +struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int
> > id);
> > +
> > +int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu);
> > +void kvm_arch_hardware_enable(void *garbage);
> > +void kvm_arch_hardware_disable(void *garbage);
> > +int kvm_arch_hardware_setup(void);
> > +void kvm_arch_hardware_unsetup(void);
> > +void kvm_arch_check_processor_compat(void *rtn);
> I don't like the generic introduction of all x86_ops wrappers into the
> arch callbacks. I would rather prefer to work out a different split
> between common and arch specifics - at least in the following cases:
> - unloading the mmu needs to be moved out of kvm_free_vcpus into the
> arch part, because we don't have a shaddow mmu on s390
> - decache_vcpus_on_cpu should be arch-dependent alltogether, rather
> than having a per cpu callback. We've got nothing to decache, so the
> entire thing is a nop for us.
> - vcpu_reset works very different for our architecture, we'd need an
> initial processor status word. I'd prefer to keep the existence of
> this callback arch dependent.
> - hardware enable/disable/setup/unsetup/check_processor_compat does not
> make any sense for us: all CPUs that have been sold since the 1970s have
> proper hardware virtualization, and there's nothing to enable - it just
> works.
Sounds fine to me: you're just proposing to move the abstraction one
level higher in some places.
--
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/
next prev parent reply other threads:[~2007-11-08 20:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-08 7:21 [PATCH]3/5 Using kvm_arch prefix to define functions, and replace Zhang, Xiantao
[not found] ` <42DFA526FC41B1429CE7279EF83C6BDC905005-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-11-08 13:49 ` Carsten Otte
[not found] ` <473313D8.4010604-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-11-08 15:05 ` [PATCH]3/5 Using kvm_arch prefix to definefunctions, " Zhang, Xiantao
[not found] ` <42DFA526FC41B1429CE7279EF83C6BDC94EE5E-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-11-11 10:48 ` Avi Kivity
2007-11-08 20:18 ` Hollis Blanchard [this message]
2007-11-09 9:01 ` [PATCH]3/5 Using kvm_arch prefix to define functions, " Carsten Otte
[not found] ` <473421E7.2070205-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-11-11 10:49 ` Avi Kivity
[not found] ` <4736DE50.5010200-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-11-12 9:16 ` Carsten Otte
[not found] ` <473819EF.2090301-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-11-12 9:50 ` Avi Kivity
2007-11-08 20:57 ` Hollis Blanchard
2007-11-09 7:25 ` [PATCH]3/5 Using kvm_arch prefix to define functions, andreplace Zhang, Xiantao
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=1194553107.22879.29.camel@basalt \
--to=hollisb-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
--cc=carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=kvm-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 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.