On 04/01/2012 06:07 PM, Michael S. Tsirkin wrote:
On Fri, Mar 30, 2012 at 11:24:10AM +0800, Asias He wrote:
Benchmark shows small performance improvement on fusion io device.
Before:
seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec
seq-write: io=1,024MB, bw=20,321KB/s, i
usage. ]
[12140.220507] 3.4.0-rc1-next-20120402-sasha #46 Tainted: GW
[12140.220507] ---
[12140.220507] include/linux/rcupdate.h:729 rcu_read_lock() used illegally
while idle!
[12140.220507]
[12140.220507] other info that might help us debug this:
[12140.2
This series attempts to make IOMMU device grouping a slightly more
integral part of the device model. iommu_device_groups were originally
introduced to support the VFIO user space driver interface which needs
to understand the granularity of device isolation in order to ensure
security of devices
IOMMU ops should be working at a group level rather than a device
level as we cannot arbitrarily assign devices from the same group
to different domains. For now this is just a simple wrapper that
makes use of the dma_dev within a group.
Signed-off-by: Alex Williamson
---
drivers/iommu/iommu.c
IOMMU groups define the minimum granularity of the IOMMU. We therefore
create groups using a dma_dev which is the effective requestor ID for
the entire group. Additional devices can be added to groups based on
system topology, IOMMU limitations, or device quirks.
This implementation also include
IOMMUs often do not have visibility of individual devices in the
system. Due to IOMMU design, bus topology, or device quirks, we
can often only identify groups of devices. Examples include
Intel VT-d & AMD-Vi which often have function level visibility
compared to POWER partitionable endpoints whi
On 2012-04-02 13:30, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.
- MSI injection to KVM irqchips from userspace devices models:
new direct MSI injection API for KVM and the right model for QEMU
to deal with the old API
- state of and plans
Hello, James.
On Mon, Apr 02, 2012 at 11:56:18AM -0700, James Bottomley wrote:
> So if we're agreed no other devices going forwards should ever use this
> interface, is there any point unifying the interface? No matter how
> many caveats you hedge it round with, putting the API in a central place
On Mon, 2012-04-02 at 11:52 -0700, Tejun Heo wrote:
> > Probably same. Renaming existing devices will break setups.
> > I think the idea is to avoid using the
> > legacy naming in new drivers *that will be added from now on*.
>
> Yeap.
So if we're agreed no other devices going forwards should eve
Hello,
On Mon, Apr 02, 2012 at 10:20:09AM +0300, Michael S. Tsirkin wrote:
> Pleae don't rename virtio disks, it is way too late for that:
> virtio block driver was merged around 2007, it is not new by
> any measure, and there are many systems out there using
> the current naming scheme.
There's
On Sat, Mar 31, 2012 at 11:22 AM, Asias He wrote:
> Hi, Stefan
>
> On Fri, Mar 30, 2012 at 6:14 PM, Stefan Hajnoczi wrote:
>> On Fri, Mar 30, 2012 at 4:24 AM, Asias He wrote:
>>> Benchmark shows small performance improvement on fusion io device.
>>>
>>> Before:
>>> seq-read : io=1,024MB, bw=19,
Anthony Liguori writes:
> So, since we're approaching 1.1, we should really discuss release
> criteria for 1.1 with respect to live migration. I'd prefer to avoid
> surprises in this release.
>
> My expectation is that migration works from:
>
> qemu-1.0 -M 1.0 =>qemu-1.1 -M 1.1
> qemu-1.
On Sun, 01 Apr 2012 11:38:17 +0800
Xiao Guangrong wrote:
> > About MMU Page Fault Path:
> > 1. Set bit in dirty bitmap
> > 2. Make spte writable
> > 3. Guest re-execute the write
> >
> > If GET_DIRTY_LOG is allowed to write protect the page between step 1 and 2,
> > that page will be made writab
On 04/02/2012 03:21 PM, Raghavendra K T wrote:
On 04/01/2012 07:23 PM, Avi Kivity wrote:
> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5127668..3fa912a 100644
--- a/virt/kvm/kv
Hi
Please send in any agenda items you are interested in covering.
Cheers,
Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On (Mon) 02 Apr 2012 [18:05:45], Wen Congyang wrote:
> At 03/19/2012 03:33 PM, Wen Congyang Wrote:
> > At 03/08/2012 03:57 PM, Wen Congyang Wrote:
> >> We can know the guest is paniced when the guest runs on xen.
> >> But we do not have such feature on kvm.
> >>
> >> Another purpose of this feature
At 03/19/2012 03:33 PM, Wen Congyang Wrote:
> At 03/08/2012 03:57 PM, Wen Congyang Wrote:
>> We can know the guest is paniced when the guest runs on xen.
>> But we do not have such feature on kvm.
>>
>> Another purpose of this feature is: management app(for example:
>> libvirt) can do auto dump whe
On 04/01/2012 07:23 PM, Avi Kivity wrote:
> On 04/01/2012 04:48 PM, Raghavendra K T wrote:
I have patch something like below in mind to try:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d3b98b1..5127668 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/k
On Mon, 2012-04-02 at 12:06 +0300, Avi Kivity wrote:
> > The current process is such that it takes absolutely forever for our
> > patches to get in, which is a major PITA for something in such state of
> > active development.
>
> If the patches were posted two weeks earlier, they would have gone i
On Fri, 2012-03-30 at 23:07 +0100, Thomas Gleixner wrote:
> So if we need to fiddle with the scheduler and frankly that's the only
> way to get a real gain (the numbers, which are achieved by this
> patches, are not that impressive) then the question arises whether we
> should turn the whole thing
On Sun, 1 Apr 2012, Avi Kivity wrote:
> On 03/31/2012 01:07 AM, Thomas Gleixner wrote:
> > On Fri, 30 Mar 2012, H. Peter Anvin wrote:
> >
> > > What is the current status of this patchset? I haven't looked at it too
> > > closely because I have been focused on 3.4 up until now...
> >
> > The real
https://bugzilla.kernel.org/show_bug.cgi?id=42779
--- Comment #26 from Avi Kivity 2012-04-02 09:12:38 ---
Strange, looks like the patches did not take effect at all. The opcode is 0f
6f 02, which should have been decoded as movq.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs
On 04/02/2012 01:45 AM, Paul Mackerras wrote:
> On Sun, Apr 01, 2012 at 03:38:37PM +0300, Avi Kivity wrote:
> > On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> > > I just noticed that the branch you asked Linus to pull includes none
> > > of the patches that Alex sent you in the last batch, in the
On 04/02/2012 12:02 AM, Benjamin Herrenschmidt wrote:
> On Sun, 2012-04-01 at 15:38 +0300, Avi Kivity wrote:
> > On 03/30/2012 03:01 PM, Paul Mackerras wrote:
> > > I just noticed that the branch you asked Linus to pull includes none
> > > of the patches that Alex sent you in the last batch, in the
Hello,
please, could somebody explain the difference in behaviour between
setting the boot option iommu=pt and not setting it?
I can see the following differences:
w/ iommu=pt:
[0.832946] AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40
[0.883983] AMD-Vi: Initialized for Passthrough Mode
On Mon, Apr 02, 2012 at 09:19:05AM +0800, Ren Mingxin wrote:
> On 03/30/2012 11:28 PM, Tejun Heo wrote:
> >On Fri, Mar 30, 2012 at 08:26:06AM -0700, Tejun Heo wrote:
> >>On Fri, Mar 30, 2012 at 05:53:52PM +0800, Ren Mingxin wrote:
> >>> The current virtblk's naming algorithm only supports 263 di
On Fri, Mar 30, 2012 at 08:26:06AM -0700, Tejun Heo wrote:
> On Fri, Mar 30, 2012 at 05:53:52PM +0800, Ren Mingxin wrote:
> > The current virtblk's naming algorithm only supports 263 disks.
> > If there are mass of virtblks(exceeding 263), there will be disks
> > with the same name.
> >
> > By r
27 matches
Mail list logo
