public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yang, Sheng" <sheng.yang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: lidong chen <chen.lidong.kernel@gmail.com>,
	Avi Kivity <avi@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Performance test result between virtio_pci MSI-X disable and enable
Date: Thu, 2 Dec 2010 09:13:28 +0800	[thread overview]
Message-ID: <201012020913.28475.sheng.yang@intel.com> (raw)
In-Reply-To: <20101201140357.GD12912@redhat.com>

On Wednesday 01 December 2010 22:03:58 Michael S. Tsirkin wrote:
> On Wed, Dec 01, 2010 at 04:41:38PM +0800, lidong chen wrote:
> > I used sr-iov, give each vm 2 vf.
> > after apply the patch, and i found performence is the same.
> > 
> > the reason is in function msix_mmio_write, mostly addr is not in mmio
> > range.
> > 
> > static int msix_mmio_write(struct kvm_io_device *this, gpa_t addr, int
> > len,
> > 
> > 			   const void *val)
> > 
> > {
> > 
> > 	struct kvm_assigned_dev_kernel *adev =
> > 	
> > 			container_of(this, struct kvm_assigned_dev_kernel,
> > 			
> > 				     msix_mmio_dev);
> > 	
> > 	int idx, r = 0;
> > 	unsigned long new_val = *(unsigned long *)val;
> > 	
> > 	mutex_lock(&adev->kvm->lock);
> > 	if (!msix_mmio_in_range(adev, addr, len)) {
> > 	
> > 		// return here.
> > 		
> >                  r = -EOPNOTSUPP;
> > 		
> > 		goto out;
> > 	
> > 	}
> > 
> > i printk the value:
> > addr             start           end           len
> > F004C00C   F0044000  F0044030     4
> > 
> > 00:06.0 Ethernet controller: Intel Corporation Unknown device 10ed (rev
> > 01)
> > 
> > 	Subsystem: Intel Corporation Unknown device 000c
> > 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > 
> > Stepping- SERR- FastB2B-
> > 
> > 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > 
> > <TAbort- <MAbort- >SERR- <PERR-
> > 
> > 	Latency: 0
> > 	Region 0: Memory at f0040000 (32-bit, non-prefetchable) [size=16K]
> > 	Region 3: Memory at f0044000 (32-bit, non-prefetchable) [size=16K]
> > 	Capabilities: [40] MSI-X: Enable+ Mask- TabSize=3
> > 	
> > 		Vector table: BAR=3 offset=00000000
> > 		PBA: BAR=3 offset=00002000
> > 
> > 00:07.0 Ethernet controller: Intel Corporation Unknown device 10ed (rev
> > 01)
> > 
> > 	Subsystem: Intel Corporation Unknown device 000c
> > 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > 
> > Stepping- SERR- FastB2B-
> > 
> > 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > 
> > <TAbort- <MAbort- >SERR- <PERR-
> > 
> > 	Latency: 0
> > 	Region 0: Memory at f0048000 (32-bit, non-prefetchable) [size=16K]
> > 	Region 3: Memory at f004c000 (32-bit, non-prefetchable) [size=16K]
> > 	Capabilities: [40] MSI-X: Enable+ Mask- TabSize=3
> > 	
> > 		Vector table: BAR=3 offset=00000000
> > 		PBA: BAR=3 offset=00002000
> > 
> > +static bool msix_mmio_in_range(struct kvm_assigned_dev_kernel *adev,
> > +			      gpa_t addr, int len)
> > +{
> > +	gpa_t start, end;
> > +
> > +	BUG_ON(adev->msix_mmio_base == 0);
> > +	start = adev->msix_mmio_base;
> > +	end = adev->msix_mmio_base + PCI_MSIX_ENTRY_SIZE *
> > +		adev->msix_max_entries_nr;
> > +	if (addr >= start && addr + len <= end)
> > +		return true;
> > +
> > +	return false;
> > +}
> 
> Hmm, this check looks wrong to me: there's no guarantee
> that guest uses the first N entries in the table.
> E.g. it could use a single entry, but only the last one.

Please check the PCI spec.

--
regards
Yang, Sheng

 
> > 2010/11/30 Yang, Sheng <sheng.yang@intel.com>:
> > > On Tuesday 30 November 2010 17:10:11 lidong chen wrote:
> > >> sr-iov also meet this problem, MSIX mask waste a lot of cpu resource.
> > >> 
> > >> I test kvm with sriov, which the vf driver could not disable msix.
> > >> so the host os waste a lot of cpu.  cpu rate of host os is 90%.
> > >> 
> > >> then I test xen with sriov, there ara also a lot of vm exits caused by
> > >> MSIX mask.
> > >> but the cpu rate of xen and domain0 is less than kvm. cpu rate of xen
> > >> and domain0 is 60%.
> > >> 
> > >> without sr-iov, the cpu rate of xen and domain0 is higher than kvm.
> > >> 
> > >> so i think the problem is kvm waste more cpu resource to deal with
> > >> MSIX mask. and we can see how xen deal with MSIX mask.
> > >> 
> > >> if this problem sloved, maybe with MSIX enabled, the performace is
> > >> better.
> > > 
> > > Please refer to my posted patches for this issue.
> > > 
> > > http://www.spinics.net/lists/kvm/msg44992.html
> > > 
> > > --
> > > regards
> > > Yang, Sheng
> > > 
> > >> 2010/11/23 Avi Kivity <avi@redhat.com>:
> > >> > On 11/23/2010 09:27 AM, lidong chen wrote:
> > >> >> can you tell me something about this problem.
> > >> >> thanks.
> > >> > 
> > >> > Which problem?
> > >> > 
> > >> > --
> > >> > I have a truly marvellous patch that fixes the bug which this
> > >> > signature is too narrow to contain.

  reply	other threads:[~2010-12-02  1:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-23  2:53 Performance test result between virtio_pci MSI-X disable and enable lidong chen
2010-11-23  6:20 ` Avi Kivity
2010-11-23  6:42   ` Gleb Natapov
2010-11-23  7:27   ` lidong chen
2010-11-23  7:39     ` Avi Kivity
2010-11-30  9:10       ` lidong chen
2010-11-30  9:24         ` Yang, Sheng
2010-12-01  8:41           ` lidong chen
2010-12-01  8:49             ` Yang, Sheng
2010-12-01  8:54               ` lidong chen
2010-12-01  9:02                 ` Yang, Sheng
2010-12-01  9:29                   ` lidong chen
2010-12-01  9:37                     ` Yang, Sheng
2010-12-01  9:34                   ` Yang, Sheng
2010-12-01  8:56             ` Yang, Sheng
2010-12-01 14:03             ` Michael S. Tsirkin
2010-12-02  1:13               ` Yang, Sheng [this message]
2010-12-02  9:49                 ` Michael S. Tsirkin
2010-12-02 11:52                   ` Sheng Yang
2010-12-02 12:23                     ` Michael S. Tsirkin
2010-12-02 14:01                       ` lidong chen
2010-12-22 13:52 ` Michael S. Tsirkin

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=201012020913.28475.sheng.yang@intel.com \
    --to=sheng.yang@intel.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=chen.lidong.kernel@gmail.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /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