Convert the AMD IOMMU driver to use the new interface for
publishing the iommu_ops.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a14f8dc..57f6f38 100
With all IOMMU drivers being converted to bus_set_iommu the
global iommu_ops are no longer required. The same is true
for the deprecated register_iommu function.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 27 ---
include/linux/iommu.h |1 -
2 files chan
The patch introduce one new command block_set_io_throttle; For its usage
syntax, if you have better idea, pls let me know.
Signed-off-by: Zhi Yong Wu
---
block.c | 26 +++-
blockdev.c | 69 +++
blockdev.h
The main goal of the patch is to effectively cap the disk I/O speed or counts
of one single VM.It is only one draft, so it unavoidably has some drawbacks, if
you catch them, please let me know.
The patch will mainly introduce one block I/O throttling algorithm, one timer
and one block queue for
> +static long vfio_iommu_unl_ioctl(struct file *filep,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct vfio_iommu *viommu = filep->private_data;
> + struct vfio_dma_map dm;
> + int ret = -ENOSYS;
> +
> + switch (cmd) {
> + case VFIO_IOMMU_M
On 08/15/2011 12:17 PM, Badari Pulavarty wrote:
On 8/14/2011 8:20 PM, Liu Yuan wrote:
On 08/13/2011 12:12 AM, Badari Pulavarty wrote:
On 8/12/2011 4:40 AM, Liu Yuan wrote:
On 08/12/2011 04:27 PM, Liu Yuan wrote:
On 08/12/2011 12:50 PM, Badari Pulavarty wrote:
On 8/10/2011 8:19 PM, Liu Yuan w
Here is how I would prefer to rework ipr.
Thanks,
Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
The PCI config space blocking API has changed to better
allow for multiple users. Update ipr to use the new API.
Signed-off-by: Brian King
---
drivers/scsi/ipr
Signed-off-by: Zhi Yong Wu
---
block.c | 59 +++
block.h |5
block_int.h |3 ++
blockdev.c | 29 +++
qemu-config.c | 24 ++
qemu-options.hx |1 +
6 fil
Note:
1.) When bps/iops limits are specified to a small value such as 511
bytes/s, this VM will hang up. We are considering how to handle this senario.
2.) When "dd" command is issued in guest, if its option bs is set to a
large value such as "bs=1024K", the result speed will slightly b
On 09/07/2011 06:56 PM, Don Zickus wrote:
>
> And hope that no other NMI was generated while we're handling this
> one. It's a little... fragile?
No. If another NMI is generated while we are processing the current one
it should get latched. Upon completion of the current one, the cpu should
Signed-off-by: Zhi Yong Wu
---
Makefile.objs |2 +-
block/blk-queue.c | 184 +
block/blk-queue.h | 59 +
block_int.h | 27
4 files changed, 271 insertions(+), 1 deletions(-)
create mode 100644 block/b
Hi,
here is the new version of the patch-set to make the iommu_ops used in
the iommu-api a bus_type property. This will allow us to move code out
of the iommu drivers into generic code and it simplifies the
implementation of the Alex' device-group property.
Greg, can you have a look at patch 2 pl
With per-bus iommu_ops the iommu_found function needs to
work on a bus_type too. This patch adds a bus_type parameter
to that function and converts all call-places.
The function is also renamed to iommu_present because the
function now checks if an iommu is present for a given bus
and does not chec
Use the per-bus iommu-ops in the functions of the iommu-api
instead of the global iommu_ops.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iomm
This is necessary to store a pointer to the bus-specific
iommu_ops in the iommu-domain structure. It will be used
later to call into bus-specific iommu-ops.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 14 +-
drivers/media/video/omap3isp/isp.c |2 +-
inc
emulate_1op_rax_rdx() is always called with the same parameters. Simplify
by passing just the emulation context.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c | 42 +-
1 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kvm/
emulate_1op() is always called with the same parameters. Simplify
by passing just the emulation context.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm
Signed-off-by: Alon Levy
---
client/bin/autotest |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/client/bin/autotest b/client/bin/autotest
index af521de..c84b771 100755
--- a/client/bin/autotest
+++ b/client/bin/autotest
@@ -21,7 +21,7 @@ os.environ['AUTODIR'] = autodir
Convert the OMAP IOMMU driver on ARM to use the new
interface for publishing the iommu_ops.
Cc: Ohad Ben-Cohen
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iom
This is the starting point to make the iommu_ops used for
the iommu-api a per-bus-type structure. It is required to
easily implement bus-specific setup in the iommu-layer.
The first user will be the iommu-group attribute in sysfs.
Signed-off-by: Joerg Roedel
---
drivers/base/bus.c | 16 +++
On 09/07/2011 04:44 PM, Don Zickus wrote:
>
> Is there a way to tell whether an NMI was internally or externally
> generated?
>
> I don't think so, especially as two or more NMIs can be coalesced.
> So any NMI received on this first cpu has to check the NMI reason
> port?
Well we cheat and
emulate_2op_SrcV(), and its siblings, emulate_2op_SrcV_nobyte()
and emulate_2op_SrcB(), all use the same calling conventions
and all get passed exactly the same parameters. Simplify them
by passing just the emulation context.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c | 90 +
We have two emulate-with-extended-accumulator implementations: once
which expect traps (_ex) and one which doesn't (plain). Drop the
plain implementation and always use the one which expects traps;
it will simply return 0 in the _ex argument and we can happily ignore
it.
Signed-off-by: Avi Kivity
emulate_2op_cl() is always called with the same parameters. Simplify
by passing just the emulation context.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index
On Wed, Sep 07, 2011 at 06:11:14PM +0300, Avi Kivity wrote:
> On 09/07/2011 04:44 PM, Don Zickus wrote:
> >>
> >> Is there a way to tell whether an NMI was internally or externally
> >> generated?
> >>
> >> I don't think so, especially as two or more NMIs can be coalesced.
> >> So any NMI recei
On Wed, Sep 07, 2011 at 07:13:58AM +0300, Avi Kivity wrote:
> On 09/06/2011 09:27 PM, Don Zickus wrote:
> >On Tue, Sep 06, 2011 at 11:07:26AM -0700, Jeremy Fitzhardinge wrote:
> >> >> But, erm, does that even make sense? I'm assuming the NMI reason port
> >> >> tells the CPU why it got an NMI.
emulate_2op_cl() is always called with the same parameters. Simplify
by passing just the emulation context.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/emulate.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/ar
Some mindless emulator cleanups while waiting for autotest.
Avi Kivity (6):
KVM: x86 emulator: simplify emulate_2op_SrcV()
KVM: x86 emulator: simplify emulate_2op_cl()
KVM: x86 emulator: simplify emulate_2op_cl()
KVM: x86 emulator: simplify emulate_1op()
KVM: x86 emulator: merge the two
Convert the MSM IOMMU driver for ARM to use the new
interface for publishing the iommu_ops.
Cc: David Brown
Signed-off-by: Joerg Roedel
---
drivers/iommu/msm_iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
i
Convert the Intel IOMMU driver to use the new interface for
publishing the iommu_ops.
Cc: David Woodhouse
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu
This makes it impossible to compile an iommu driver into the
kernel without selecting CONFIG_IOMMU_API.
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 994031
On 09/07/2011 07:15 AM, Alon Levy wrote:
Signed-off-by: Alon Levy
Looks good to me, applied, thanks!
http://autotest.kernel.org/changeset/5575
---
client/bin/autotest |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/client/bin/autotest b/client/bin/autotest
index
On Wed, Sep 07, 2011 at 07:25:24PM +0300, Avi Kivity wrote:
> On 09/07/2011 06:56 PM, Don Zickus wrote:
> >>
> >> And hope that no other NMI was generated while we're handling this
> >> one. It's a little... fragile?
> >
> >No. If another NMI is generated while we are processing the current one
Avi Kivity wrote:
>>
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -229,6 +229,8 @@
>> #define MSR_IA32_APICBASE_ENABLE (1<<11)
>> #define MSR_IA32_APICBASE_BASE (0xf<<12)
>>
>> +#define MSR_IA32_TSCDEADLINE0x06
On Wed, 07 Sep 2011 14:07:49 +0800, Amos Kong wrote:
> System services on guest and host take uncertain resource, it effects
> the perf results. We can use the below two scripts to disable some
> services of host and guest.
>
> stop_serivices_perf.sh is used to stop the running serivices.
On 09/07/2011 07:45 PM, Liu, Jinsong wrote:
Avi Kivity wrote:
>>
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -229,6 +229,8 @@
>>#define MSR_IA32_APICBASE_ENABLE(1<<11)
>>#define MSR_IA32_APICBASE_BASE (0xf<<12)
>>
>> +
On 09/07/2011 07:52 PM, Don Zickus wrote:
>
> May I ask how? Detecting a back-to-back NMI?
Pretty boring actually. Currently we execute an NMI handler until one of
them returns handled. Then we stop. This may cause us to miss an NMI in
the case of multiple NMIs at once. Now we are changing
On 09/07/2011 10:09 AM, Avi Kivity wrote:
> On 09/07/2011 07:52 PM, Don Zickus wrote:
>> >
>> > May I ask how? Detecting a back-to-back NMI?
>>
>> Pretty boring actually. Currently we execute an NMI handler until
>> one of
>> them returns handled. Then we stop. This may cause us to miss an
>>
On Tue, Sep 6, 2011 at 11:25 PM, TooMeeK wrote:
> First, I created mirrored storage in hypervisor from one 600-gig partition
> (yes, that's correct - I have only one drive currently), details:
> sudo mdadm --detail /dev/md3
> /dev/md3:
> Version : 1.2
> Creation Time : Thu Jul 28 20:07:00
On Wed, Sep 07, 2011 at 08:09:37PM +0300, Avi Kivity wrote:
> On 09/07/2011 07:52 PM, Don Zickus wrote:
> >>
> >> May I ask how? Detecting a back-to-back NMI?
> >
> >Pretty boring actually. Currently we execute an NMI handler until one of
> >them returns handled. Then we stop. This may cause u
Avi Kivity wrote:
> On 09/07/2011 07:45 PM, Liu, Jinsong wrote:
>> Avi Kivity wrote:
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -229,6 +229,8 @@
#define MSR_IA32_APICBASE_ENABLE(1<<11)
#define MSR_IA32_APICBASE_BA
On 09/07/2011 08:17 PM, Jeremy Fitzhardinge wrote:
On 09/07/2011 10:09 AM, Avi Kivity wrote:
> On 09/07/2011 07:52 PM, Don Zickus wrote:
>> >
>> > May I ask how? Detecting a back-to-back NMI?
>>
>> Pretty boring actually. Currently we execute an NMI handler until
>> one of
>> them retur
On 09/07/2011 08:21 PM, Don Zickus wrote:
>
> How about, during NMI, save %rip to a per-cpu variable. Handle just
> one cause. If, on the next NMI, we hit the same %rip, assume
> back-to-back NMI has occured and now handle all causes.
I had a similar idea a couple of months ago while debugg
Signed-off-by: Hagen Paul Pfeifer
Cc: Sasha Levin
Cc: Pekka Enberg
---
tools/kvm/builtin-run.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/tools/kvm/builtin-run.c b/tools/kvm/builtin-run.c
index 725c23c..53ab911 100644
--- a/tools/kvm/builtin-run.c
+++ b/tools/kvm/
On Wed, Sep 07, 2011 at 05:41:45PM +0200, Joerg Roedel wrote:
> This is the starting point to make the iommu_ops used for
> the iommu-api a per-bus-type structure. It is required to
> easily implement bus-specific setup in the iommu-layer.
> The first user will be the iommu-group attribute in sysfs
On Wed, Sep 07, 2011 at 05:41:43PM +0200, Joerg Roedel wrote:
> Hi,
>
> here is the new version of the patch-set to make the iommu_ops used in
> the iommu-api a bus_type property. This will allow us to move code out
> of the iommu drivers into generic code and it simplifies the
> implementation of
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to d
On Thu, Sep 01, 2011 at 01:50:50PM -0600, Alex Williamson wrote:
> Signed-off-by: Alex Williamson
> ---
>
> drivers/vfio/Kconfig|7 ++
> drivers/vfio/Makefile |1
> drivers/vfio/vfio_main.c| 10 +++
> drivers/vfio/vfio_pci.c | 124
>
On 09/07/2011 10:41 AM, Avi Kivity wrote:
>> Hm, I'm interested to know what you're thinking in more detail. Can you
>> leave an NMI pending before you block in the same way you can with
>> "sti;halt" with normal interrupts?
>
>
> Nope. But you can do
>
>if (regs->rip in critical section)
>
Hi Greg,
the bus_set_iommu() function will be called by the IOMMU driver. There
can be different drivers for the same bus, depending on the hardware. On
PCI for example, there can be the Intel or the AMD IOMMU driver that
implement the iommu-api and that register for that bus.
On Wed, Sep 07, 201
On Wed, Sep 07, 2011 at 11:48:40AM -0700, Greg KH wrote:
> On Wed, Sep 07, 2011 at 05:41:43PM +0200, Joerg Roedel wrote:
> > Diffstat:
> >
> > arch/ia64/kvm/kvm-ia64.c |3 +-
> > arch/x86/kvm/x86.c |3 +-
> > drivers/base/bus.c | 16 ++
>
On Wed, Sep 07, 2011 at 09:19:19PM +0200, Joerg Roedel wrote:
> Hi Greg,
>
> the bus_set_iommu() function will be called by the IOMMU driver. There
> can be different drivers for the same bus, depending on the hardware. On
> PCI for example, there can be the Intel or the AMD IOMMU driver that
> im
On 01.09.2011, at 21:50, Alex Williamson wrote:
> Trying to move beyond talking about how VFIO should work to
> re-writing the code. This is pre-alpha, known broken, will
> probably crash your system but it illustrates some of how
> I see groups, devices, and iommus interacting. This is just
>
On 09/07/2011 03:44 PM, Greg KH wrote:
On Wed, Sep 07, 2011 at 09:19:19PM +0200, Joerg Roedel wrote:
Hi Greg,
the bus_set_iommu() function will be called by the IOMMU driver. There
can be different drivers for the same bus, depending on the hardware. On
PCI for example, there can be the Intel o
On 09/07/11 00:25, TooMeeK wrote:
Next, I've tried following combinations with virt-manager 0.8.4 (from
XML of VM):
1.on Debian VM with virtio drivers for both storage and NIC:
partition type used in guest: EXT4
result: poor performance, 9-10MB/s sequentional copy via SMB
2.on Debian VM with
On 09/07/11 00:25, TooMeeK wrote:
Next, I've tried following combinations with virt-manager 0.8.4 (from
XML of VM):
1.on Debian VM with virtio drivers for both storage and NIC:
partition type used in guest: EXT4
result: poor performance, 9-10MB/s sequentional copy via SMB
2.on Debian VM wit
The Buildbot has detected a new failure on builder default_i386_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/959
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure on builder default_x86_64_out_of_tree
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/898
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this
The Buildbot has detected a new failure on builder default_x86_64_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/957
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Bu
The Buildbot has detected a new failure on builder default_i386_out_of_tree
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/896
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Buil
The Buildbot has detected a new failure on builder
disable_kvm_x86_64_debian_5_0 while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/947
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for
The Buildbot has detected a new failure on builder disable_kvm_i386_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/948
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for thi
The Buildbot has detected a new failure on builder disable_kvm_i386_out_of_tree
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/896
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for t
The Buildbot has detected a new failure on builder
disable_kvm_x86_64_out_of_tree while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_out_of_tree/builds/896
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave f
The Buildbot has detected a new failure on builder i386 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/i386/builds/294
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly scheduler named 'n
The Buildbot has detected a new failure on builder ppc64 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/ppc64/builds/298
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly scheduler named
The Buildbot has detected a new failure on builder s390 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/s390/builds/294
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly scheduler named 'n
The Buildbot has detected a new failure on builder x86_64 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/x86_64/builds/305
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly scheduler name
The Buildbot has detected a new failure on builder ppc44x while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/ppc44x/builds/301
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly scheduler name
The Buildbot has detected a new failure on builder next-x86_64 while building
kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-x86_64/builds/283
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly sch
The Buildbot has detected a new failure on builder next-ppc44x while building
kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-ppc44x/builds/283
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly sch
The Buildbot has detected a new failure on builder next-s390 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-s390/builds/285
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly schedule
The Buildbot has detected a new failure on builder next-i386 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-i386/builds/283
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly schedule
The Buildbot has detected a new failure on builder next-ppc64 while building
kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-ppc64/builds/284
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly sched
On 9/7/11 5:34 AM, "Michael S. Tsirkin" wrote:
> On Tue, Sep 06, 2011 at 03:35:40PM -0700, Roopa Prabhu wrote:
>> This patch is an attempt at providing address filtering support for macvtap
>> devices in PASSTHRU mode. Its still a work in progress.
>> Briefly tested for basic functionality. Wante
75 matches
Mail list logo
