All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Benoît Canet" <benoit.canet-J9ArbTHlV+bR7s880joybQ@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: VFIO and scheduled SR-IOV cards
Date: Wed, 10 Jul 2013 13:23:55 +0300	[thread overview]
Message-ID: <20130710102355.GB10203@redhat.com> (raw)
In-Reply-To: <20130604155030.GA5991-J9ArbTHlV+bR7s880joybQ@public.gmane.org>

On Tue, Jun 04, 2013 at 05:50:30PM +0200, Benoît Canet wrote:
> 
> Hello,
> 
> More informations on how the hardware works.
> 
> -Each VF will have its own memory and MMR, etc.
> That means the resources are not shared.
> 
> -Each VF will have its own bus number, function number and device number.
> That means request ID is separated for each VF.
> 
> There is also VF save/restore area for the switch.
> 
> A VF regular memory (not MMR) is still accessible after a switch out.
> 
> But when a function VF1 is scheduled a read to a MRR of VF number 0 could return
> the value of the same MMR in VF number 1 because VF number 1 is switched on and
> the PF processor is busy servicing VF number 1.
> 
> This could confuse the guest VF driver so the unmap and block or a same goal
> achieving technique is required.
> 
> I hope these informations makes the area of the problem to solve narrower.
> 
> Best regards
> 
> Benoît Canet

Confused.
You have one VF accessing BAR of another VF?
Why?

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Benoît Canet" <benoit.canet@irqsave.net>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Don Dutile <ddutile@redhat.com>,
	iommu@lists.linux-foundation.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] VFIO and scheduled SR-IOV cards
Date: Wed, 10 Jul 2013 13:23:55 +0300	[thread overview]
Message-ID: <20130710102355.GB10203@redhat.com> (raw)
In-Reply-To: <20130604155030.GA5991@irqsave.net>

On Tue, Jun 04, 2013 at 05:50:30PM +0200, Benoît Canet wrote:
> 
> Hello,
> 
> More informations on how the hardware works.
> 
> -Each VF will have its own memory and MMR, etc.
> That means the resources are not shared.
> 
> -Each VF will have its own bus number, function number and device number.
> That means request ID is separated for each VF.
> 
> There is also VF save/restore area for the switch.
> 
> A VF regular memory (not MMR) is still accessible after a switch out.
> 
> But when a function VF1 is scheduled a read to a MRR of VF number 0 could return
> the value of the same MMR in VF number 1 because VF number 1 is switched on and
> the PF processor is busy servicing VF number 1.
> 
> This could confuse the guest VF driver so the unmap and block or a same goal
> achieving technique is required.
> 
> I hope these informations makes the area of the problem to solve narrower.
> 
> Best regards
> 
> Benoît Canet

Confused.
You have one VF accessing BAR of another VF?
Why?

-- 
MST

  parent reply	other threads:[~2013-07-10 10:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03 16:33 VFIO and scheduled SR-IOV cards Benoît Canet
2013-06-03 16:33 ` [Qemu-devel] " Benoît Canet
     [not found] ` <20130603163305.GC4094-J9ArbTHlV+bR7s880joybQ@public.gmane.org>
2013-06-03 18:02   ` Alex Williamson
2013-06-03 18:02     ` [Qemu-devel] " Alex Williamson
     [not found]     ` <1370282529.30975.344.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-06-03 18:34       ` Don Dutile
2013-06-03 18:34         ` [Qemu-devel] " Don Dutile
     [not found]         ` <51ACE1B5.2050102-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-06-03 18:57           ` Alex Williamson
2013-06-03 18:57             ` [Qemu-devel] " Alex Williamson
     [not found]             ` <1370285865.30975.361.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-06-04 15:50               ` Benoît Canet
2013-06-04 15:50                 ` Benoît Canet
     [not found]                 ` <20130604155030.GA5991-J9ArbTHlV+bR7s880joybQ@public.gmane.org>
2013-06-04 18:31                   ` Alex Williamson
2013-06-04 18:31                     ` Alex Williamson
2013-07-10 10:23                   ` Michael S. Tsirkin [this message]
2013-07-10 10:23                     ` Michael S. Tsirkin
     [not found]                     ` <20130710102355.GB10203-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-28 15:17                       ` Benoît Canet
2013-07-28 15:17                         ` Benoît Canet

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=20130710102355.GB10203@redhat.com \
    --to=mst-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=benoit.canet-J9ArbTHlV+bR7s880joybQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@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.