On Wed, Feb 01, 2012 at 03:46:52PM +1100, David Gibson wrote:
> In order to safely drive a device with a userspace driver, or to pass
> it through to a guest system, we must first make sure that the device
> is isolated in such a way that it cannot interfere with other devices
> on the system. Thi
On Thu, Feb 09, 2012 at 08:39:28AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2012-02-08 at 16:27 +0100, Joerg Roedel wrote:
> > Again, device grouping is done by the IOMMU drivers, so this all
> > belongs
> > into the generic iommu-code rather than the driver core.
&
On Wed, Dec 07, 2011 at 09:54:39AM -0600, Stuart Yoder wrote:
> Alex, Alexey I'm wondering if you've had any new thoughts on this over
> the last week.
>
> For Freescale, our iommu domain attributes would look something like:
> -domain iova base address
> -domain iova window size
I agree
On Thu, Dec 15, 2011 at 11:05:07AM -0700, Alex Williamson wrote:
> Starting with it in the core and hand waving some future use that we
> don't plan to implement right now seems like the wrong direction.
I agree with Alex. First of all, I havn't seen any real vfio problem
that can't be solved with
On Mon, Dec 19, 2011 at 11:11:25AM +1100, David Gibson wrote:
> Well.. that's not where it is in Alex's code either. The iommu layer
> (to the extent that there is such a "layer") supplies the group info,
> but the group management is in vfio, not the iommu layer. With mine
> it is in the driver
On Wed, Dec 21, 2011 at 02:32:35PM +1100, David Gibson wrote:
> On Mon, Dec 19, 2011 at 04:41:56PM +0100, Joerg Roedel wrote:
> > For 1) I think the current solution with the iommu_group file is fine.
> > It is somewhat expensive for user-space to figure out the per-group
> >
To let the user configure the desired tsc frequency for the
guest if running in KVM.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h |1 +
target-i386/cpuid.c | 10 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index
Make use of the KVM_TSC_CONTROL feature if available.
Signed-off-by: Joerg Roedel
---
target-i386/kvm.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 1ae2d61..2d89544 100644
--- a/target-i386/kvm.c
+++ b/target
Diffstat:
target-i386/cpu.h |1 +
target-i386/cpuid.c | 10 ++
target-i386/kvm.c | 11 +++
3 files changed, 22 insertions(+), 0 deletions(-)
Shortlog:
Joerg Roedel (2):
qemu-x86: Add tsc_khz option to -cpu
qemu-x86: Set tsc_khz in kvm when supported
This function does the same as the strtosz_suffix function
except that it allows to specify the unit to which the
k/M/B/T suffixes apply. This function will be used later to
parse the tsc-frequency from the command-line.
Signed-off-by: Joerg Roedel
---
cutils.c | 16
Hi Avi, Marcelo,
here is v2 of the patches to support setting the guests tsc-frequency
from the qemu command line. This version addresses the comment from Avi
on the first version. To reflect that units can be given to the
frequency, the parameter was renamed from tsc_khz to tsc_freq.
Thanks,
To let the user configure the desired tsc frequency for the
guest if running in KVM.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h |1 +
target-i386/cpuid.c | 13 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
Make use of the KVM_TSC_CONTROL feature if available.
Signed-off-by: Joerg Roedel
---
target-i386/kvm.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 10fb2c4..923d2d5 100644
--- a/target-i386/kvm.c
+++ b
On Tue, Jul 19, 2011 at 03:20:37PM +0300, Avi Kivity wrote:
> On 07/19/2011 02:46 PM, Marcelo Tosatti wrote:
>> On Thu, Jul 07, 2011 at 04:13:12PM +0200, Joerg Roedel wrote:
>> > To let the user configure the desired tsc frequency for the
>> > guest if running in KV
On Tue, Jul 19, 2011 at 04:55:53PM +0300, Avi Kivity wrote:
> On 07/19/2011 04:54 PM, Avi Kivity wrote:
>> On 07/19/2011 04:30 PM, Joerg Roedel wrote:
>>> Hmm, I planned to do the VMSTATE thing in a follow-on patch-set. The
>>> plan is to read the VCPU tsc_freq at gue
On Mon, Aug 22, 2011 at 02:30:26AM -0400, Avi Kivity wrote:
> On 08/20/2011 07:51 PM, Alex Williamson wrote:
> > We need to address both the description and enforcement of device
> > groups. Groups are formed any time the iommu does not have resolution
> > between a set of devices. On x86, this t
On Sat, Aug 20, 2011 at 12:51:39PM -0400, Alex Williamson wrote:
> We had an extremely productive VFIO BoF on Monday. Here's my attempt to
> capture the plan that I think we agreed to:
>
> We need to address both the description and enforcement of device
> groups. Groups are formed any time the
On Mon, Aug 22, 2011 at 08:52:18PM -0400, aafabbri wrote:
> You have to enforce group/iommu domain assignment whether you have the
> existing uiommu API, or if you change it to your proposed
> ioctl(inherit_iommu) API.
>
> The only change needed to VFIO here should be to make uiommu fd assignment
On Tue, Aug 23, 2011 at 02:54:43AM -0400, Benjamin Herrenschmidt wrote:
> Possibly, the question that interest me the most is what interface will
> KVM end up using. I'm also not terribly fan with the (perceived)
> discrepancy between using uiommu to create groups but using the group fd
> to actual
On Tue, Aug 23, 2011 at 03:30:06PM -0400, Alex Williamson wrote:
> On Tue, 2011-08-23 at 07:01 +1000, Benjamin Herrenschmidt wrote:
> > Could be tho in what form ? returning sysfs pathes ?
>
> I'm at a loss there, please suggest. I think we need an ioctl that
> returns some kind of array of devi
On Tue, Aug 23, 2011 at 01:33:14PM -0400, Aaron Fabbri wrote:
> On 8/23/11 10:01 AM, "Alex Williamson" wrote:
> > The iommu domain would probably be allocated when the first device is
> > bound to vfio. As each device is bound, it gets attached to the group.
> > DMAs are done via an ioctl on the
On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> > We need to solve this differently. ARM is starting to use the iommu-api
> > too and this definitly does not work there. One possible solution might
> > be to make the iomm
On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:
> On 26.08.2011, at 04:33, Roedel, Joerg wrote:
> >
> > The reason is that you mean the usability for the programmer and I mean
> > it for the actual user of qemu :)
>
> No, we mean the actual user of qemu. The reason being that maki
On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote:
> On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>> The biggest problem with this approach is that it has to happen in the
>> context of the given process. Linux can't really modify an mm which
>> which belong to another context in a safe w
On Fri, Aug 26, 2011 at 12:04:22PM -0600, Alex Williamson wrote:
> On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> > If we really expect segment numbers that need the full 16 bit then this
> > would be the way to go. Otherwise I would prefer returning the group-id
&
On Sun, Aug 28, 2011 at 05:04:32PM +0300, Avi Kivity wrote:
> On 08/28/2011 04:56 PM, Joerg Roedel wrote:
>> This can't be secured by a lock, because it introduces potential
>> A->B<-->B->A lock problem when two processes try to take each others mm.
>>
On Tue, Apr 09, 2013 at 01:22:15AM +, Yoder Stuart-B08248 wrote:
> > What happens if a normal unmap call is done on the MSI iova? Do we
> > need a separate unmap?
>
> I was thinking a normal unmap on an MSI windows would be an error...but
> I'm not set on that. I put the msi unmap there to
On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
> One correction: it's a feature of the device in the system.
> There could be a mix of devices bypassing and not
> bypassing the IOMMU.
No, it really is not. A device can't chose to bypass the IOMMU. But the
IOMMU can chose to le
On Wed, Apr 27, 2016 at 05:34:30PM +0300, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote:
> QEMU can choose to bypass IOMMU for one device and not the other.
> IOMMU in QEMU isn't involved when it's bypassed.
And it is QEMU's ta
On Wed, Apr 27, 2016 at 05:54:57PM +0300, Michael S. Tsirkin wrote:
> Point is, QEMU is not the only virtio implementation out there.
> So we can't know no virtio implementations have an IOMMU as long as
> linux supports this IOMMU.
> virtio always used physical addresses since it was born and if i
On Sat, Aug 28, 2010 at 04:00:31PM +, Blue Swirl wrote:
> On Sat, Aug 28, 2010 at 2:54 PM, Eduard - Gabriel Munteanu
> > Please have a look and merge if you like it.
>
> The endianess bug still exists. I had also other comments to 2.
I am very happy with this patch set. Besides your comments
This patch cleans the (stack-allocated) cpuid definition to
0 before actually initializing it.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 5fa0dd0..5735795 100644
Hi,
this patch-set adds the svm cpuid feature flags to qemu-kvm. With this
patch-set the npt feature-flag can be presented to the guest so that it will
use nested-paging when emulated by the host kvm. Please review, comment and/or
apply these patches :-)
Thanks,
Joerg
This patch adds the svm cpuid feature flags to the qemu
intialization path.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h |1 +
target-i386/cpuid.c | 50 +-
target-i386/kvm.c |3 +++
3 files changed, 45 insertions(+), 9 deletions
This patch changes the setting logic for the svm bit in
qemu-kvm. The bit is now explicitly set on -enable-nesting
instead of masked out if the parameter is not supplied.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions
This patch adds the svm cpuid feature flags to the qemu
intialization path.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h | 12 +++
target-i386/cpuid.c | 80 ---
target-i386/kvm.c |3 ++
3 files changed, 78 insertions(+), 17
This patch cleans the (stack-allocated) cpuid definition to
0 before actually initializing it.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 04ba8d5..3fcf78f 100644
Hi again,
this is the new version of the patches that add the SVM feature flags to qemu.
I rebased the patches to qemu.git. These patches are required to let the guests
see the svm flag and additional svm features like nested paging as well. Please
have a look at them and let me knwo your opinion
On Sat, Sep 11, 2010 at 03:43:02PM +0200, Alexander Graf wrote:
> > @@ -305,6 +322,8 @@ static x86_def_t builtin_x86_defs[] = {
> > CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
> > .ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
> > CPUID_EXT3_ABM | CPUID_EXT3_S
On Sat, Sep 11, 2010 at 04:29:18PM +0200, Alexander Graf wrote:
> > Depends on which Phenom you have. A Phenom II has NRIPSAVE but the old
> > Phenoms don't have it. For the SVM features it is not that important
> > what the host hardware supports but what KVM can emulate. VMCBCLEAN can
> > be emul
On Sat, Sep 11, 2010 at 04:38:51PM +0200, Alexander Graf wrote:
> > I am not sure that I am the right person to do such an invasive change.
> > At least not in this patch-set. I could think of removing SVM from the
> > qemu64 definition and add it again in the TCG specific path.
>
> It's not an in
On Sun, Sep 12, 2010 at 10:01:28AM +0200, Avi Kivity wrote:
> On 09/12/2010 09:16 AM, Alexander Graf wrote:
>> Either way, I don't think we need a phenom2 type. The features
>> additional are minor enough to not really matter and all use cases I
>> can come up with require either -cpu host (local
As requested by Alex this patch makes kvm64 the default CPU
model when qemu is started with -enable-kvm.
Signed-off-by: Joerg Roedel
---
hw/pc.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 69b13bf..f531d0d 100644
--- a/hw
This patch cleans the (stack-allocated) cpuid definition to
0 before actually initializing it.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 04ba8d5..3fcf78f 100644
Hi,
here is the next round of the svm feature support patches for qemu. Key
change in this version is that it now makes kvm{64|32} the default cpu
definition for qemu when kvm is enabled (as requested by Alex).
Otherwise I removed the NRIP_SAVE feature from the phenom definition and
set svm_featur
This patch adds the svm cpuid feature flags to the qemu
intialization path. It also adds the svm features available
on phenom to its cpu-definition and extends the host cpu
type to support all svm features KVM can provide.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h | 12
Hi,
here is the third round of the patches to add svm-features support to
qemu. The patches are rebases against latest qemu/master. Other changes
since v2:
* Made kvm64 the default model only for qemu-versions >= 0.14.0
* Removed clean-bits from the phenom cpu-model
Feedback and/
This patch cleans the (stack-allocated) cpuid definition to
0 before actually initializing it.
Signed-off-by: Joerg Roedel
---
target-i386/cpuid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 04ba8d5..3fcf78f 100644
As requested by Alex this patch makes kvm64 the default CPU
model when qemu is started with -enable-kvm. This takes only
effect for qemu-versions newer or equal to 0.14.0.
Signed-off-by: Joerg Roedel
---
hw/boards.h|1 +
hw/pc.c| 21 -
hw/pc_piix.c |6
This patch adds the svm cpuid feature flags to the qemu
intialization path. It also adds the svm features available
on phenom to its cpu-definition and extends the host cpu
type to support all svm features KVM can provide.
Signed-off-by: Joerg Roedel
---
target-i386/cpu.h | 12
Hello David,
On Thu, Apr 21, 2011 at 03:03:47AM -0400, David Gibson wrote:
> A few months ago, Eduard - Gabriel Munteanu posted a series of patches
> implementing support for emulating the AMD PCI IOMMU
> (http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg03196.html).
>
> In fact, this s
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> > Memory accesses must go through the IOMMU layer.
>
> No. Devices should not know or care whether an IOMMU is present.
There are real devices that care very much about an IOMMU. Basically all
devices supporting ATS care about that. So
On Wed, Jul 14, 2010 at 04:29:18PM -0500, Anthony Liguori wrote:
> On 07/14/2010 03:13 PM, Paul Brook wrote:
>> Well, ok, the function name needs fixing too. However I think the only thing
>> missing from the current API is that it does not provide a way to determine
>> which device is performing
On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
> A device performs a memory access on its local bus. It has no knowledge of
> how
> that access is routed to its destination. The device should not be aware of
> any IOMMUs, in the same way that it doesn't know whether it happens to
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
> On 07/15/2010 04:10 AM, Joerg Roedel wrote:
>> If this means a seperate interface for device dma accesses and not fold
>> that functionality into the cpu_physical_memory* interface I agree too :-)
>>
>
On Thu, Jul 15, 2010 at 11:49:20AM +0100, Paul Brook wrote:
> > An IOMMU is not necessarily part of a bus bridge. By concept an IOMMU
> > can also be implemented on a plugin-card translating only that card.
> > Real implementations that I am aware of always implement the IOMMU in
> > the PCI root
On Thu, Jul 15, 2010 at 08:02:05PM +0300, Avi Kivity wrote:
> For emulated device, it seems like we can ignore ATS completely, no?
An important use-case for emulation is software testing and caching of
iommu's is an important part that needs to be handled in software. For
this purpose it makes se
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
> On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> > - The -minimum- granularity of pass-through is not always a single
> > device and not always under SW control
>
> But IMHO, we need to preserve the granularity of
Hi Eduard,
On Thu, May 20, 2010 at 04:50:07PM +0300, Eduard - Gabriel Munteanu wrote:
> + --enable-amd-iommu-emul) amd_iommu="yes"
> + ;;
A compile-time option is a good idea.
> +/* MMIO registers */
> +#define MMIO_DEVICE_TABLE 0x
> +#define MMIO_COMMAND_BASE 0x0008
> +#define
On Mon, May 24, 2010 at 08:10:16PM +, Blue Swirl wrote:
> On Mon, May 24, 2010 at 3:40 PM, Joerg Roedel wrote:
> >> +
> >> +#define MMIO_SIZE 0x2028
> >
> > This size should be a power-of-two value. In this case probably 0x4000.
>
> Not
On Mon, Mar 15, 2010 at 02:25:41PM +0200, Avi Kivity wrote:
> On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
>> Hi there,
>>
>> Our wiki page for the Summer of Code 2010 is doing quite well:
>>
>> http://wiki.qemu.org/Google_Summer_of_Code_2010
>>
>
> I will add another project - iommu emul
On Mon, Mar 15, 2010 at 05:53:13AM -0700, Muli Ben-Yehuda wrote:
> On Mon, Mar 15, 2010 at 02:25:41PM +0200, Avi Kivity wrote:
> > On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
>
> > > Hi there,
> > >
> > > Our wiki page for the Summer of Code 2010 is doing quite well:
> > >
> > >http://wiki.qe
On Mon, Mar 15, 2010 at 03:11:42PM +0200, Avi Kivity wrote:
> On 03/15/2010 03:03 PM, Joerg Roedel wrote:
>>
>>>> I will add another project - iommu emulation. Could be very useful
>>>> for doing device assignment to nested guests, which could make
>>>&g
On Mon, Mar 15, 2010 at 08:14:29AM -0500, Anthony Liguori wrote:
> On 03/15/2010 07:42 AM, Avi Kivity wrote:
>> On 03/15/2010 02:38 PM, Joerg Roedel wrote:
>>> On Mon, Mar 15, 2010 at 02:25:41PM +0200, Avi Kivity wrote:
>>>> On 03/10/2010 11:30 PM, Luiz Capit
On Tue, Mar 30, 2010 at 08:06:36PM +0300, Blue Swirl wrote:
> On 3/30/10, Eduard - Gabriel Munteanu wrote:
> > hw/iommu.c concerns the SPARC IOMMU. However we intend to implement the
> > AMD IOMMU, which could lead to confusion unless we rename the former.
>
> I was also thinking of renaming the
Hello Eduard,
On Tue, Mar 30, 2010 at 11:20:01AM +0300, Eduard - Gabriel Munteanu wrote:
> This patchset is intended to provide a start for implementing the
> emulation of the AMD IOMMU. For those who aren't aware yet, I intend
> to participate as a student in GSoC 2010.
Great. This is a good sta
Hello Roland, Luiz,
Sorry I missed this email. Here is my reply.
On Wed, Apr 07, 2010 at 09:57:27AM -0300, Luiz Capitulino wrote:
> On Tue, 6 Apr 2010 18:56:17 +0200
> Roland Elek wrote:
>
> > Seeing the controversy about the S3 Trio, and the fact that there seems to
> > be another applicant in
On Sat, May 01, 2010 at 10:50:56AM -0300, Lucas Meneghel Rodrigues wrote:
> Hi folks, on during the latest upstream test job I noticed that the
> -mem-path option got broken on latest qemu-kvm. qemu abnormally ends
> with exit code 1 when trying to call it with -mem-path
>
> 04/29 18:35:32 DEBUG|
On Sun, May 09, 2010 at 09:11:17PM +0200, Alexander Graf wrote:
> Sebastian Herbszt wrote:
> > The ICH6 AHCI implementation submitted by Chong is an all-in-one
> > attempt (ahci.c).
> > It includes all needed parts of the ICH6, AHCI, SATA and ATA
> > specification.
> > The code in hw/ide/* on the o
On Tue, May 11, 2010 at 01:19:27AM +0200, Alexander Graf wrote:
>
> On 11.05.2010, at 00:13, Sebastian Herbszt wrote:
> >
> > The problem of incremental patches will be a non issue as soon as the git
> > tree is available.
>
> I set up a mailing list and a git tree for development. The mailing
70 matches
Mail list logo
