public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Gregory Haskins" <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
To: "Chris Wright" <chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH] Support for in-kernel mmio handlers
Date: Wed, 04 Apr 2007 19:04:12 -0400	[thread overview]
Message-ID: <4613E891.BA47.005A.0@novell.com> (raw)
In-Reply-To: <20070404224806.GA15078-JyIX8gxvWYPr2PDY2+4mTGD2FQJk+8+b@public.gmane.org>

Hi Chris,
  Thanks for the feedback.  Ive answered inline below.

>>> On Wed, Apr 4, 2007 at  6:48 PM, in message
<20070404224806.GA15078-JyIX8gxvWYPr2PDY2+4mTGD2FQJk+8+b@public.gmane.org>, Chris Wright
<chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org> wrote: 
> * Gregory Haskins (ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org) wrote:
>> The MMIO registration code has been broken out as a new patch from the 
> in- kernel APIC work with the following changes per Avi's request:
>> 
>> 1) Supports dynamic registration
>> 2) Uses gpa_t addresses
>> 3) Explicit per- cpu mappings
>> 
>> In addition, I have added the concept of distinct VCPU and VM level 
> registrations (where VCPU devices will eclipse competing VM registrations (if 
> any).  This will be key down the road where LAPICs should use VCPU 
> registration, but IOAPICs should use VM level.
> 
> hmm, i'm surprised it makes a difference.

LAPICs can be remapped on a per-cpu basis via an MSR, whereas something like an IOAPIC is a system-wide resource.

> 
>> Signed- off- by: Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
>> 
>> ---
>>  drivers/kvm/kvm.h      |   50 +++++++++++++++++++++++++++++++++++++++++++++
>>  drivers/kvm/kvm_main.c |   53 +++++++++++++++++++++++++++++++++++++++--------
>>  2 files changed, 94 insertions(+), 9 deletions(- )
>> 
>> diff -- git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
>> index fceeb84..3334730 100644
>> ---  a/drivers/kvm/kvm.h
>> +++ b/drivers/kvm/kvm.h
>> @@ - 236,6 +236,54 @@ struct kvm_pio_request {
>>  	int rep;
>>  };
>>  
>> +struct kvm_io_device {
>> +	unsigned long (*read)(struct kvm_io_device *this,
>> +			      gpa_t addr,
>> +			      unsigned long length);
>> +	void (*write)(struct kvm_io_device *this,
>> +		      gpa_t addr,
>> +		      unsigned long length,
>> +		      unsigned long val);
>> +	int (*in_range)(struct kvm_io_device *this, gpa_t addr);
>> +
>> +	void             *private;
> 
> This looks unused, what is it meant for?

Its unused in this patch, because the primary consumer is a follow on patch that is not yet released.  The original patch had this logic + the logic that used it all together and it was requested to break them apart.


> 
>> +	struct list_head  link;
>> +};
>> +
>> +/* It would be nice to use something smarter than a linear search, TBD...
>> +   Thankfully we dont expect many devices to register (famous last words 
> :),
>> +   so until then it will suffice.  At least its abstracted so we can change
>> +   in one place.
>> + */
>> +struct kvm_io_bus {
>> +	struct list_head list;
>> +};
>> +
>> +static inline void 
>> +kvm_io_bus_init(struct kvm_io_bus *bus)
>> +{
>> +	INIT_LIST_HEAD(&bus- >list);
>> +}
>> +
>> +static inline struct kvm_io_device* 
>> +kvm_io_bus_find_dev(struct kvm_io_bus *bus, gpa_t addr)
>> +{
>> +	struct kvm_io_device *pos = NULL;
>> +
>> +	list_for_each_entry(pos, &bus- >list, link) {
>> +		if(pos- >in_range(pos, addr))
> 
> linux style nit, missing space after if -- > if (pos- >in_range(pos, addr))

Yeah, old habits die hard ;)  I will fix all of these.

> 
>> +			return pos;
>> +	}
>> +
>> +	return NULL;
>> +}
>> +
>> +static inline void 
>> +kvm_io_bus_register_dev(struct kvm_io_bus *bus, struct kvm_io_device *dev)
>> +{
>> +	list_add_tail(&dev- >link, &bus- >list);
>> +}
>> +
>>  struct kvm_vcpu {
>>  	struct kvm *kvm;
>>  	union {
>> @@ - 294,6 +342,7 @@ struct kvm_vcpu {
>>  	gpa_t mmio_phys_addr;
>>  	struct kvm_pio_request pio;
>>  	void *pio_data;
>> +	struct kvm_io_bus mmio_bus;
>>  
>>  	int sigset_active;
>>  	sigset_t sigset;
>> @@ - 345,6 +394,7 @@ struct kvm {
>>  	unsigned long rmap_overflow;
>>  	struct list_head vm_list;
>>  	struct file *filp;
>> +	struct kvm_io_bus mmio_bus;
>>  };
>>  
>>  struct kvm_stat {
>> diff -- git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
>> index 4473174..da119c0 100644
>> ---  a/drivers/kvm/kvm_main.c
>> +++ b/drivers/kvm/kvm_main.c
>> @@ - 294,6 +294,7 @@ static struct kvm *kvm_create_vm(void)
>>  
>>  	spin_lock_init(&kvm- >lock);
>>  	INIT_LIST_HEAD(&kvm- >active_mmu_pages);
>> +	kvm_io_bus_init(&kvm- >mmio_bus);
> 
> I'd just do INIT_LIST_HEAD, unless you havd bigger plans for this wrapper?

The motivation for wrapping the init is because I want to abstract the fact that its a list.   This means I can update the mechanism to do something more intelligent with address lookup (e.g. b-tree, etc) without changing code all over the place.  Right now there are only two consumers, put I envision there will be some more.  For instance, I would like to get PIOs using this mechanism at some point (so I can snarf accesses to the 8259s at 0x20/0xa0)


> 
>>  	for (i = 0; i < KVM_MAX_VCPUS; ++i) {
>>  		struct kvm_vcpu *vcpu = &kvm- >vcpus[i];
>>  
>> @@ - 302,6 +303,7 @@ static struct kvm *kvm_create_vm(void)
>>  		vcpu- >kvm = kvm;
>>  		vcpu- >mmu.root_hpa = INVALID_PAGE;
>>  		INIT_LIST_HEAD(&vcpu- >free_pages);
>> +		kvm_io_bus_init(&vcpu- >mmio_bus);
> 
> ditto
> 
>>  		spin_lock(&kvm_lock);
>>  		list_add(&kvm- >vm_list, &vm_list);
>>  		spin_unlock(&kvm_lock);
>> @@ - 1015,12 +1017,30 @@ static int emulator_write_std(unsigned long addr,
>>  	return X86EMUL_UNHANDLEABLE;
>>  }
>>  
>> +static struct kvm_io_device* vcpu_find_mmio_dev(struct kvm_vcpu *vcpu, 
>> +						gpa_t addr)
>> +{
>> +	struct kvm_io_device *mmio_dev;
>> +
>> +	/* First check the local CPU addresses */
>> +	mmio_dev = kvm_io_bus_find_dev(&vcpu- >mmio_bus, addr);
>> +	if(!mmio_dev) {
> 
> same style nit.  

ack

> and why do you have local vs global check 

see my first comment: re LAPIC is a relocateble per-cpu resource, IOAPIC is not

>(or dynamic  registration for that matter)?

the xAPIC support will be optional, so the ability to register for MMIO handing has to be dynamic.

> 
>> +		/* Then check the entire VM */
>> +		mmio_dev = kvm_io_bus_find_dev(&vcpu- >kvm- >mmio_bus, addr);
>> +	}
>> +	
>> +	return mmio_dev;
>> +}
>> +
>>  static int emulator_read_emulated(unsigned long addr,
>>  				  unsigned long *val,
>>  				  unsigned int bytes,
>>  				  struct x86_emulate_ctxt *ctxt)
>>  {
>>  	struct kvm_vcpu *vcpu = ctxt- >vcpu;
>> +	gpa_t gpa;
>> +	int i;
>> +	struct kvm_io_device *mmio_dev;
>>  
>>  	if (vcpu- >mmio_read_completed) {
>>  		memcpy(val, vcpu- >mmio_data, bytes);
>> @@ - 1029,18 +1049,24 @@ static int emulator_read_emulated(unsigned long addr,
>>  	} else if (emulator_read_std(addr, val, bytes, ctxt)
>>  		   == X86EMUL_CONTINUE)
>>  		return X86EMUL_CONTINUE;
>> -	else {
>> -		gpa_t gpa = vcpu- >mmu.gva_to_gpa(vcpu, addr);
>>  
>> -		if (gpa == UNMAPPED_GVA)
>> -			return X86EMUL_PROPAGATE_FAULT;
>> -		vcpu- >mmio_needed = 1;
>> -		vcpu- >mmio_phys_addr = gpa;
>> -		vcpu- >mmio_size = bytes;
>> -		vcpu- >mmio_is_write = 0;
>> +	gpa = vcpu- >mmu.gva_to_gpa(vcpu, addr);
>> +	if (gpa == UNMAPPED_GVA)
>> +		return vcpu_printf(vcpu, "not present\n"), X86EMUL_PROPAGATE_FAULT;
>>  
>> -		return X86EMUL_UNHANDLEABLE;
>> +	/* Is thie MMIO handled locally? */
> 
> s/thie/this/

ack

> 
>> +	mmio_dev = vcpu_find_mmio_dev(vcpu, gpa);
>> +	if(mmio_dev) {
> 
> style

ack

> 
>> +		*val = mmio_dev- >read(mmio_dev, gpa, bytes);
>> +		return X86EMUL_CONTINUE;
>>  	}
>> +
>> +	vcpu- >mmio_needed = 1;
>> +	vcpu- >mmio_phys_addr = gpa;
>> +	vcpu- >mmio_size = bytes;
>> +	vcpu- >mmio_is_write = 0;
>> +	
>> +	return X86EMUL_UNHANDLEABLE;
>>  }
>>  
>>  static int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
>> @@ - 1070,6 +1096,8 @@ static int emulator_write_emulated(unsigned long addr,
>>  {
>>  	struct kvm_vcpu *vcpu = ctxt- >vcpu;
>>  	gpa_t gpa = vcpu- >mmu.gva_to_gpa(vcpu, addr);
>> +	int i;
>> +	struct kvm_io_device *mmio_dev;
>>  
>>  	if (gpa == UNMAPPED_GVA)
>>  		return X86EMUL_PROPAGATE_FAULT;
>> @@ - 1077,6 +1105,13 @@ static int emulator_write_emulated(unsigned long addr,
>>  	if (emulator_write_phys(vcpu, gpa, val, bytes))
>>  		return X86EMUL_CONTINUE;
>>  
>> +	/* Is thie MMIO handled locally? */
> 
> s/thie/this/

ack

> 
>> +	mmio_dev = vcpu_find_mmio_dev(vcpu, gpa);
>> +	if(mmio_dev) {
> 
> style

ack

> 
>> +		mmio_dev- >write(mmio_dev, gpa, bytes, val);
>> +		return X86EMUL_CONTINUE;
>> +	}
>> +
>>  	vcpu- >mmio_needed = 1;
>>  	vcpu- >mmio_phys_addr = gpa;
>>  	vcpu- >mmio_size = bytes;

Regards,
-Greg


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

  parent reply	other threads:[~2007-04-04 23:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-04 20:42 [PATCH] Support for in-kernel mmio handlers Gregory Haskins
     [not found] ` <4613C73F.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-04 22:48   ` Chris Wright
     [not found]     ` <20070404224806.GA15078-JyIX8gxvWYPr2PDY2+4mTGD2FQJk+8+b@public.gmane.org>
2007-04-04 23:04       ` Gregory Haskins [this message]
     [not found]         ` <20070405001021.GV10574@sequoia.sous-sol.org>
     [not found]           ` <20070405001021.GV10574-JyIX8gxvWYPr2PDY2+4mTGD2FQJk+8+b@public.gmane.org>
2007-04-05  0:21             ` Gregory Haskins
     [not found]         ` <4613E891.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-05  0:49           ` Chris Wright
2007-04-05  7:07   ` Avi Kivity
     [not found]     ` <4614A03C.2050707-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-05  7:29       ` Dor Laor
2007-04-05 14:58       ` Gregory Haskins
     [not found]         ` <4614C844.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-08  7:38           ` Avi Kivity
2007-04-08  8:49           ` Avi Kivity
     [not found]             ` <4618AC94.3040700-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-09 14:14               ` Gregory Haskins
     [not found]                 ` <461A03F3.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-10  7:56                   ` Avi Kivity
     [not found]                     ` <461B4319.80608-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-10 11:49                       ` Gregory Haskins
     [not found]                         ` <461B4176.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-10 12:02                           ` Avi Kivity
2007-04-05  7:46   ` Avi Kivity
     [not found]     ` <4614A973.6020102-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-05 13:23       ` Gregory Haskins
     [not found]         ` <4614B1FE.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-04-05 13:45           ` Avi Kivity

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=4613E891.BA47.005A.0@novell.com \
    --to=ghaskins-et1tbqhtxzrqt0dzr+alfa@public.gmane.org \
    --cc=chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@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