public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org,
	Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
	Xiantao <xiantao.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1 of 3] Use kvm_x86 to hold x86 specific	kvm fields
Date: Wed, 28 Nov 2007 15:43:13 -0600	[thread overview]
Message-ID: <1196286193.9247.30.camel@basalt> (raw)
In-Reply-To: <474DDB97.6090400-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>

On Wed, 2007-11-28 at 15:20 -0600, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
> > --- a/drivers/kvm/ioapic.c
> > +++ b/drivers/kvm/ioapic.c
> > @@ -276,7 +276,9 @@ static int get_eoi_gsi(struct kvm_ioapic
> >  
> >  void kvm_ioapic_update_eoi(struct kvm *kvm, int vector)
> >  {
> > -     struct kvm_ioapic *ioapic = kvm->vioapic;
> > +     struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
> > +
> > +     struct kvm_ioapic *ioapic = kvm_x86->vioapic;
> >       union ioapic_redir_entry *ent;
> >       int gsi;
> >  
> > @@ -386,11 +388,12 @@ int kvm_ioapic_init(struct kvm *kvm)
> >  int kvm_ioapic_init(struct kvm *kvm)
> >  {
> >       struct kvm_ioapic *ioapic;
> > +     struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
> >  
> >       ioapic = kzalloc(sizeof(struct kvm_ioapic), GFP_KERNEL);
> >       if (!ioapic)
> >               return -ENOMEM;
> > -     kvm->vioapic = ioapic;
> > +     kvm_x86->vioapic = ioapic;
> >       kvm_ioapic_reset(ioapic);
> >       ioapic->dev.read = ioapic_mmio_read;
> >       ioapic->dev.write = ioapic_mmio_write;
> >   
> 
> If the ioapic depends on x86_specific information, why is it taking a 
> generic kvm structure instead of the x86 one?

Fine, I can move the conversion up into x86.c .

> > diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> > --- a/drivers/kvm/kvm_main.c
> > +++ b/drivers/kvm/kvm_main.c
> > @@ -232,6 +232,7 @@ int __kvm_set_memory_region(struct kvm *
> >       unsigned long i;
> >       struct kvm_memory_slot *memslot;
> >       struct kvm_memory_slot old, new;
> > +     struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
> >  
> >       r = -EINVAL;
> >       /* General sanity checks */
> > @@ -332,18 +333,18 @@ int __kvm_set_memory_region(struct kvm *
> >       if (mem->slot >= kvm->nmemslots)
> >               kvm->nmemslots = mem->slot + 1;
> >  
> > -     if (!kvm->n_requested_mmu_pages) {
> > +     if (!kvm_x86->n_requested_mmu_pages) {
> >   
> 
> Why is anything in kvm_main.c accessing a memory of kvm_x86?
> Something is broken in the abstraction if that's the case.

kvm_main.c was chock full of x86 code. The fact that there's still a
little bit remaining (even after all our work so far) shouldn't be
surprising.

> >               unsigned int n_pages;
> >  
> >               if (npages) {
> >                       n_pages = npages * KVM_PERMILLE_MMU_PAGES /
> 1000;
> > -                     kvm_mmu_change_mmu_pages(kvm,
> kvm->n_alloc_mmu_pages +
> > -                                              n_pages);
> > +                     kvm_mmu_change_mmu_pages(kvm,
> > +                                       kvm_x86->n_alloc_mmu_pages +
> n_pages);
> >               } else {
> >                       unsigned int nr_mmu_pages;
> >  
> >                       n_pages = old.npages *
> KVM_PERMILLE_MMU_PAGES / 1000;
> > -                     nr_mmu_pages = kvm->n_alloc_mmu_pages -
> n_pages;
> > +                     nr_mmu_pages = kvm_x86->n_alloc_mmu_pages -
> n_pages;
> >                       nr_mmu_pages = max(nr_mmu_pages,
> >                                       (unsigned int)
> KVM_MIN_ALLOC_MMU_PAGES);
> >                       kvm_mmu_change_mmu_pages(kvm, nr_mmu_pages);
> > diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
> > --- a/drivers/kvm/mmu.c
> > +++ b/drivers/kvm/mmu.c
> > @@ -526,12 +526,14 @@ static void kvm_mmu_free_page(struct kvm
> >  static void kvm_mmu_free_page(struct kvm *kvm,
> >                             struct kvm_mmu_page *page_head)
> >  {
> > +     struct kvm_x86 *kvm_x86 = to_kvm_x86(kvm);
> > +
> >       ASSERT(is_empty_shadow_page(page_head->spt));
> >       list_del(&page_head->link);
> >       __free_page(virt_to_page(page_head->spt));
> >       __free_page(virt_to_page(page_head->gfns));
> >       kfree(page_head);
> > -     ++kvm->n_free_mmu_pages;
> > +     ++kvm_x86->n_free_mmu_pages;
> >  }
> 
> The mmu functions should probably take kvm_x86 since this won't be 
> shared with any other architecture.

Sure, and that can be addressed in the future. However, changing all of
that code at once results in a far larger patch, and this patch works
as-is.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

  parent reply	other threads:[~2007-11-28 21:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 16:57 [PATCH 0 of 3] create kvm_x86 Hollis Blanchard
2007-11-20 16:57 ` [PATCH 1 of 3] Use kvm_x86 to hold x86 specific kvm fields Hollis Blanchard
2007-11-28 21:20   ` Anthony Liguori
     [not found]     ` <474DDB97.6090400-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-11-28 21:43       ` Hollis Blanchard [this message]
2007-11-20 16:57 ` [PATCH 2 of 3] Move vm_stat and apic_access_page to kvm_x86 Hollis Blanchard
2007-11-21  9:09 ` [PATCH 0 of 3] create kvm_x86 Carsten Otte
     [not found]   ` <4743F5AE.8090707-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-11-21  9:18     ` Avi Kivity
     [not found]       ` <4743F7DF.4000107-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-11-21  9:32         ` Amit Shah
2007-11-21  9:39         ` Carsten Otte
2007-11-21  9:42         ` Zhang, Xiantao
     [not found]           ` <42DFA526FC41B1429CE7279EF83C6BDC9E7193-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-11-21  9:55             ` Avi Kivity
2007-11-28 21:15         ` Hollis Blanchard
2007-11-30  7:26           ` Avi Kivity
     [not found]             ` <474FBB17.6080800-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-11-30  8:36               ` Zhang, Xiantao
     [not found]                 ` <42DFA526FC41B1429CE7279EF83C6BDCA397C1-wq7ZOvIWXbMAbVU2wMM1CrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-11-30  9:04                   ` Avi Kivity
     [not found]                     ` <474FD234.5060203-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-11-30 11:42                       ` Zhang, Xiantao
2007-11-30 18:43                       ` Hollis Blanchard
2007-11-30 20:31                         ` Avi Kivity
     [not found]                           ` <4750732B.7070502-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-11-30 21:09                             ` Hollis Blanchard
2007-11-30 21:43                               ` Anthony Liguori
     [not found]                                 ` <47508408.8050202-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-11-30 22:08                                   ` Hollis Blanchard
2007-12-01 10:04                                     ` Avi Kivity
2007-12-01 10:02                               ` 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=1196286193.9247.30.camel@basalt \
    --to=hollisb-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=anthony-rdkfGonbjUSkNkDKm+mE6A@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=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