From: Sheng Yang <sheng@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] KVM: Emulate MSI-X table in kernel
Date: Thu, 24 Feb 2011 17:44:20 +0800 [thread overview]
Message-ID: <201102241744.21007.sheng@linux.intel.com> (raw)
In-Reply-To: <20110223084400.GA17290@redhat.com>
On Wednesday 23 February 2011 16:45:37 Michael S. Tsirkin wrote:
> On Wed, Feb 23, 2011 at 02:59:04PM +0800, Sheng Yang wrote:
> > On Wednesday 23 February 2011 08:19:21 Alex Williamson wrote:
> > > On Sun, 2011-01-30 at 13:11 +0800, Sheng Yang wrote:
> > > > Then we can support mask bit operation of assigned devices now.
> > >
> > > Looks pretty good overall. A few comments below. It seems like we
> > > should be able to hook this into vfio with a small stub in kvm. We
> > > just need to be able to communicate disabling and enabling of
> > > individual msix vectors. For brute force, we could do this with a lot
> > > of eventfds, triggered by kvm and consumed by vfio, two per MSI-X
> > > vector. Not sure if there's something smaller that could do it.
> > > Thanks,
> >
> > Alex, thanks for your comments. See my comments below:
> > > Alex
> > >
> > > > Signed-off-by: Sheng Yang <sheng@linux.intel.com>
> > > > ---
> > > >
> > > > arch/x86/kvm/Makefile | 2 +-
> > > > arch/x86/kvm/x86.c | 8 +-
> > > > include/linux/kvm.h | 21 ++++
> > > > include/linux/kvm_host.h | 25 ++++
> > > > virt/kvm/assigned-dev.c | 44 +++++++
> > > > virt/kvm/kvm_main.c | 38 ++++++-
> > > > virt/kvm/msix_mmio.c | 286
> > > > ++++++++++++++++++++++++++++++++++++++++++++++ virt/kvm/msix_mmio.h
> > > >
> > > > | 25 ++++
> > > >
> > > > 8 files changed, 442 insertions(+), 7 deletions(-)
> > > > create mode 100644 virt/kvm/msix_mmio.c
> > > > create mode 100644 virt/kvm/msix_mmio.h
> > > >
> > > > diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> > > > index f15501f..3a0d851 100644
> > > > --- a/arch/x86/kvm/Makefile
> > > > +++ b/arch/x86/kvm/Makefile
> > > > @@ -7,7 +7,7 @@ CFLAGS_vmx.o := -I.
> > > >
> > > > kvm-y += $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o
\
> > > >
> > > > coalesced_mmio.o irq_comm.o eventfd.o \
> > > >
> > > > - assigned-dev.o)
> > > > + assigned-dev.o msix_mmio.o)
> > > >
> > > > kvm-$(CONFIG_IOMMU_API) += $(addprefix ../../../virt/kvm/, iommu.o)
> > > > kvm-$(CONFIG_KVM_ASYNC_PF) += $(addprefix ../../../virt/kvm/,
> > > > async_pf.o)
> > > >
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index fa708c9..89bf12c 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -1966,6 +1966,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> > > >
> > > > case KVM_CAP_X86_ROBUST_SINGLESTEP:
> > > > case KVM_CAP_XSAVE:
> > > >
> > > > case KVM_CAP_ASYNC_PF:
> > > > + case KVM_CAP_MSIX_MMIO:
> > > > r = 1;
> > > > break;
> > > >
> > > > case KVM_CAP_COALESCED_MMIO:
> > > > @@ -3807,6 +3808,7 @@ static int
> > > > emulator_write_emulated_onepage(unsigned long addr,
> > > >
> > > > struct kvm_vcpu *vcpu)
> > > >
> > > > {
> > > >
> > > > gpa_t gpa;
> > > >
> > > > + int r;
> > > >
> > > > gpa = kvm_mmu_gva_to_gpa_write(vcpu, addr, exception);
> > > >
> > > > @@ -3822,14 +3824,16 @@ static int
> > > > emulator_write_emulated_onepage(unsigned long addr,
> > > >
> > > > mmio:
> > > > trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, *(u64 *)val);
> > > >
> > > > + r = vcpu_mmio_write(vcpu, gpa, bytes, val);
> > > >
> > > > /*
> > > >
> > > > * Is this MMIO handled locally?
> > > > */
> > > >
> > > > - if (!vcpu_mmio_write(vcpu, gpa, bytes, val))
> > > > + if (!r)
> > > >
> > > > return X86EMUL_CONTINUE;
> > > >
> > > > vcpu->mmio_needed = 1;
> > > >
> > > > - vcpu->run->exit_reason = KVM_EXIT_MMIO;
> > > > + vcpu->run->exit_reason = (r == -ENOTSYNC) ?
> > > > + KVM_EXIT_MSIX_ROUTING_UPDATE : KVM_EXIT_MMIO;
>
> This use of -ENOTSYNC is IMO confusing.
> How about we make vcpu_mmio_write return the positive exit reason?
> Negative value will mean an error.
In fact currently nagative value means something more need to be done, the same as
MMIO exit. Now I think we can keep it, or update them all later.
--
regards
Yang, Sheng
next prev parent reply other threads:[~2011-02-24 9:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-30 5:11 [PATCH 0/3 v8] MSI-X MMIO support for KVM Sheng Yang
2011-01-30 5:11 ` [PATCH 1/3] KVM: Move struct kvm_io_device to kvm_host.h Sheng Yang
2011-01-30 5:11 ` [PATCH 2/3] KVM: Emulate MSI-X table in kernel Sheng Yang
2011-02-03 1:05 ` Marcelo Tosatti
2011-02-18 8:15 ` Sheng Yang
2011-02-22 17:58 ` Marcelo Tosatti
2011-02-23 0:19 ` Alex Williamson
2011-02-23 6:59 ` Sheng Yang
2011-02-23 8:45 ` Michael S. Tsirkin
2011-02-24 8:08 ` Sheng Yang
2011-02-24 10:11 ` Michael S. Tsirkin
2011-02-25 5:54 ` Sheng Yang
2011-02-24 9:44 ` Sheng Yang [this message]
2011-02-24 10:17 ` Michael S. Tsirkin
2011-02-25 6:12 ` Sheng Yang
2011-02-25 8:46 ` Michael S. Tsirkin
2011-02-23 16:34 ` Alex Williamson
2011-02-23 18:39 ` Michael S. Tsirkin
2011-02-23 19:02 ` Alex Williamson
2011-01-30 5:11 ` [PATCH 3/3] KVM: Add documents for MSI-X MMIO API Sheng Yang
-- strict thread matches above, loose matches on Subject: below --
2011-01-06 10:19 [PATCH 0/3 v7] MSI-X MMIO support for KVM Sheng Yang
2011-01-06 10:19 ` [PATCH 2/3] KVM: Emulate MSI-X table in kernel Sheng Yang
2011-01-17 11:54 ` Marcelo Tosatti
2011-01-17 12:18 ` Sheng Yang
2011-01-17 12:18 ` Avi Kivity
2011-01-17 12:48 ` Marcelo Tosatti
2011-01-17 12:51 ` Avi Kivity
2011-01-17 15:52 ` Marcelo Tosatti
2011-01-17 16:01 ` Avi Kivity
2011-01-17 12:39 ` Marcelo Tosatti
2011-01-19 8:37 ` Sheng Yang
2011-01-17 12:29 ` Avi Kivity
2011-01-17 13:31 ` Michael S. Tsirkin
2011-01-17 13:47 ` Jan Kiszka
2011-01-30 4:38 ` Sheng Yang
2011-01-31 13:09 ` Avi Kivity
2011-02-01 4:21 ` Sheng Yang
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=201102241744.21007.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
/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.