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 renaming
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 disks.
If
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
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 email
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 email
https://bugzilla.kernel.org/show_bug.cgi?id=42779
--- Comment #26 from Avi Kivity a...@redhat.com 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:
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 question is
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 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 in.
I
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/kvm_main.c
@@ -1608,15
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 when the
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 is:
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 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
---
On Sun, 01 Apr 2012 11:38:17 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com 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
Anthony Liguori anth...@codemonkey.ws 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
On Sat, Mar 31, 2012 at 11:22 AM, Asias He asias.he...@gmail.com wrote:
Hi, Stefan
On Fri, Mar 30, 2012 at 6:14 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Mar 30, 2012 at 4:24 AM, Asias He as...@redhat.com wrote:
Benchmark shows small performance improvement on fusion io device.
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 no
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 ever use
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 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
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
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 alex.william...@redhat.com
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
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
. ]
[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.220507
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,
27 matches
Mail list logo
