This series is a follow up to this thread:
http://www.spinics.net/lists/netdev/msg191360.html
This adds two NTF_XXX bits to signal if the PF_BRIDGE
netlink command should be parsed by the embedded bridge
or the SW bridge. The insight here is the SW bridge is
always the master device (NTF_MASTER)
This adds a dev_uc_add_excl() call similar to the original
dev_uc_add() except it sets the global bit. With this
change the reference count will not be bumped and -EEXIST
will be returned if a duplicate address exists.
This is useful for drivers that support SR-IOV and want
to manage the unicast l
This adds a generic dump routine drivers can call. It
should be sufficient to handle any bridging model that
uses the unicast address list. This should be most SR-IOV
enabled NICs.
Signed-off-by: John Fastabend
---
net/core/rtnetlink.c | 56 ++
Enable FDB ops on ixgbe when in SR-IOV mode.
Signed-off-by: John Fastabend
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 59 +
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/in
This allows RAR table updates while in promiscuous. With
SR-IOV enabled it is valuable to allow the RAR table to
be updated even when in promisc mode to configure forwarding
Signed-off-by: John Fastabend
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 21 +++--
1 files cha
On Mon, Mar 19, 2012 at 12:20:30PM +0530, shashank rachamalla wrote:
> On Sun, Mar 18, 2012 at 10:21 PM, Gleb Natapov wrote:
> > On Sun, Mar 18, 2012 at 09:47:55PM +0530, shashank rachamalla wrote:
> >> >> I guess things are working fine with perf. But why not with oprofile ?
> >> >>
> >> > Looks
Forgot to change the title resending with a title that won't
be dropped by netdev and kvm mailing lists. And updated my
local repo so it won't happen again.
---
This adds two new flags NTF_MASTER and NTF_LOWERDEV that can
now be used to specify where PF_BRIDGE netlink commands should
be sent. NTF
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 guest is crashed. If management
> app does n
Hi,
Alon Levy wrote:
Thanks for the patch, but I think you are using a not up to date tree,
it's fixed by:
commit 0202181245297a9e847c05f4a18623219d95e93e
Author: Hans de Goede
Date: Fri Mar 2 16:49:44 2012 +0100
libcacard: Fix compilation with gcc-4.7
(same fix).
My fault, sorry f
On 03/18/2012 10:47 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2012-03-18 at 12:23 +0200, Avi Kivity wrote:
> > -ENODOCS
>
> What kind of docs do you expect ? Where ?
Documentation/virtual/kvm/api.txt.
> I don't see any of the other
> private ioctls we use on ppc documented either...
>
Please
On 03/16/2012 05:44 PM, Takuya Yoshikawa wrote:
> On Fri, 16 Mar 2012 16:28:56 +0800
> Xiao Guangrong wrote:
>
>> Thanks for your explanation, maybe you are right, i do not know migration
>> much.
>>
>> What i worried about is, you have changed the behaviour of GET_DIRTY_LOG,
>> in the current o
On Sun, Feb 05, 2012 at 12:16:01PM +0100, Paolo Bonzini wrote:
> This commit adds basic error handling to the virtio-scsi
> HBA device. Task management functions are sent synchronously
> via the control virtqueue.
>
> Cc: linux-scsi
> Cc: Rusty Russell
> Cc: Michael S. Tsirkin
> Cc: kvm@vger.k
If the host or the device does not support INTx sharing, retry the IRQ
assignment with host-side MSI support enabled but warn about potential
consequences. This allows to preserve the previous behavior where we
defaulted to MSI and did not support INTx sharing at all.
Signed-off-by: Jan Kiszka
--
On Fri, Mar 16, 2012 at 04:59:35PM +0800, Amos Kong wrote:
> On 14/03/12 19:46, Stefan Hajnoczi wrote:
> >On Wed, Mar 14, 2012 at 10:46 AM, Avi Kivity wrote:
> >>On 03/14/2012 12:39 PM, Stefan Hajnoczi wrote:
> >>>On Wed, Mar 14, 2012 at 10:05 AM, Avi Kivity wrote:
> On 03/14/2012 11:59 AM, S
On Mon, 19 Mar 2012 17:34:49 +0800
Xiao Guangrong wrote:
> The current code is under the protection of s-rcu:
> IIRC, it always holds s-rcu when write guest page and set dirty bit,
> that mean the dirty page is logged either in the old dirty_bitmap or in the
> current memslot->dirty_bitmap. Yes?
On 03/16/2012 10:59 AM, Amos Kong wrote:
>
> Can you give some detail about this? I'm not familiar with Memory API.
Well there's a huge amount of detail needed here. The idea is that
memory_region_add_eventfd() will always work, with or without kvm, and
even if kvm is enabled but we run out of io
On Fri, Mar 16, 2012 at 11:13:31AM +0100, David Cure wrote:
> hello,
>
> sorry for the delay,
>
> Le Thu, Feb 23, 2012 at 10:38:07AM +0200, Gleb Natapov ecrivait :
> >
> > Ah, I guess the reason is that it records events only of IO thread. You
> > need to trace all vcpu threa
On 03/19/2012 08:14 AM, Zhang, Yang Z wrote:
> The new logic is compatible with old. So it should not block migrate from old
> version. But new version cannot migrate to old.
>
> +static int rtc_load_old(QEMUFile *f, void *opaque, int version_id)
> +{
> +RTCState *s = opaque;
> +
> +if (ve
Il 19/03/2012 10:55, Hu Tao ha scritto:
> + int ret = FAILED;
>
> cmd->comp = ∁
> ret = virtscsi_kick_cmd(vscsi, vscsi->ctrl_vq, cmd,
> sizeof cmd->req.tmf, sizeof cmd->resp.tmf,
> GFP_NOIO);
> if (ret < 0)
> -
On Sun, Mar 18, 2012 at 11:10:43PM +0100, Alexander Graf wrote:
> Hence I asked Paul to take on temporary maintainership of the
> kvm-ppc tree for the next 3 weeks. During that time, he'll be
> allowed to send pull requests to Avi and Marcelo and is obliged to
> fix the build whenever it breaks :)
On 03/19/2012 01:56 PM, Paul Mackerras wrote:
> On Sun, Mar 18, 2012 at 11:10:43PM +0100, Alexander Graf wrote:
>
> > Hence I asked Paul to take on temporary maintainership of the
> > kvm-ppc tree for the next 3 weeks. During that time, he'll be
> > allowed to send pull requests to Avi and Marcelo
On 03/16/2012 12:19 AM, Daniel Lezcano wrote:
> Hi all,
>
> I recently did some modification in the cpuidle core and the patches
> were merge to linux-next.
> Someone reported a problem with the intel_idle cpuidle driver.
>
> I tried to reproduce the problem with kvm but the kernel fails to
> intia
On 03/19/2012 01:31 PM, Avi Kivity wrote:
On 03/16/2012 12:19 AM, Daniel Lezcano wrote:
Hi all,
I recently did some modification in the cpuidle core and the patches
were merge to linux-next.
Someone reported a problem with the intel_idle cpuidle driver.
I tried to reproduce the problem with kv
Those patches make tcp migration use the help functions in
qemu-socket.c for support IPv6 migration.
Changes from v1:
- split different changes to small patches, it will be easier to review
- fixed some problem according to Kevin's comment
Changes from v2:
- fix issue of returning real error
- s
Change inet_connect(const char *str, int socktype) to
inet_connect(const char *str, bool block, int *sock_err),
socktype is unused, block is used to assign if set socket
to block/nonblock, sock_err is used to restore socket error.
Connect's successful for nonblock socket when following errors are
Use help functions in qemu-socket.c for tcp migration,
which already support ipv6 addresses.
For IPv6 brackets must be mandatory if you require a port.
Referencing to RFC5952, the recommended format is:
[2312::8274]:5200
test status: Successed
listen side: qemu-kvm -incoming tcp:[2312:
It is necessary for adding syncdata class.
Signed-off-by: Jiří Župka
---
client/common_lib/base_barrier.py |2 +-
client/common_lib/base_utils.py| 65 ++
.../kvm/tests/migration_with_file_transfer.py |6 +-
client/tests/kvm/test
Multihost migration framework makes multi host migration
guest with load easy. This patch also replaces old tests
for multihost migration with version which using the framework.
Multihost miration framework take care about:
- preparing environment before migration
- preparing guest for migrati
Include i8254-kvm.c instead of building it as a separate module. This
allows to reduce the diff to upstream and will help with merging the
latter.
Signed-off-by: Jan Kiszka
---
Makefile.target |1 -
hw/i8254-kvm.c | 12
hw/i8254.c | 43 +
pit_load_old is only called with version_id == 1, but
PIT_SAVEVM_VERSION is 2. So this function is broken in qemu_kvm for
ages, and also the dummy qemu_get_be32 is pointless. Revert to upstream.
Signed-off-by: Jan Kiszka
---
hw/i8254.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
pit_irq_timer_update now checks generically if a channel IRQ is
disabled, so we can drop the hacks from qemu-kvm.
Signed-off-by: Jan Kiszka
---
hw/i8254.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/hw/i8254.c b/hw/i8254.c
index 7089832..befad05 10
The IRQ output line is reset along with the HPET (via signaling a new
state on the corresponding GPIO line), not the PIT itself.
Signed-off-by: Jan Kiszka
---
hw/i8254.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw/i8254.c b/hw/i8254.c
index befad05..ca24ab9 1006
Due to old-style-only creation of the in-kernel PIT (became broken long
ago during refactorings), the kernel always handled the speaker port in
qemu-kvm for a long while. Thus all bits that try to make the user space
speaker emulating kvm-aware are actually unused. Upstream will come with
fully-wor
Some preparation patches to arrange qemu-kvm for merging in latest qemu
with its own in-kernel PIT support. Later on, we can switch to that
version without losing features on the way, even just temporarily.
Jan Kiszka (5):
qemu-kvm: i8254/pcspk: Remove unused bits to make PC speaker
kvm-awar
On Mon, 2012-03-19 at 10:56 +0100, Jan Kiszka wrote:
> If the host or the device does not support INTx sharing, retry the IRQ
> assignment with host-side MSI support enabled but warn about potential
> consequences. This allows to preserve the previous behavior where we
> defaulted to MSI and did no
Currently virtio-pci is specified so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual PCI device).
However, Linux guests happen to use ioread/iowrite/iomap primitives
for access, and these work uniformly across memory/io BARs.
While PCI IO accesses are fast
Hi, in a minute I'll send a new version of the MSR_IA32_FEATURE_CONTROL
patch for nested VMX; I just wanted to reply first to your comments so
you'll know what to expect:
On Wed, Mar 07, 2012, Avi Kivity wrote about "Re: PATCH: nVMX: Better
MSR_IA32_FEATURE_CONTROL handling":
> On 03/07/2012 05:5
All corresponding binaries are now in pc-bios, so we can remove this
diff to upstream.
Signed-off-by: Jan Kiszka
---
Makefile |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 908954c..1bc3cb0 100644
--- a/Makefile
+++ b/Makefile
@@ -294,12 +2
The existing code emulated the guest's use of the IA32_FEATURE_CONTROL MSR
in a way that was enough to run nested VMX guests, but did not fully
conform to the VMX specification, and in particular did not allow a guest
BIOS to prevent the guest OS from using VMX by setting the lock bit on this
MSR.
On Fri, Mar 16, 2012 at 10:30:35AM +0530, Akshay Karle wrote:
> >> +/* kvm tmem foundation ops/hypercalls */
> >> +
> >> +static inline int kvm_tmem_op(u32 tmem_cmd, u32 tmem_pool, struct
> >> tmem_oid oid,
> >> + u32 index, u32 tmem_offset, u32 pfn_offset, unsigned long pfn, u32 len,
> >> uint1
On 03/19/2012 07:49 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 16, 2012 at 10:30:35AM +0530, Akshay Karle wrote:
> > >> +/* kvm tmem foundation ops/hypercalls */
> > >> +
> > >> +static inline int kvm_tmem_op(u32 tmem_cmd, u32 tmem_pool, struct
> > >> tmem_oid oid,
> > >> +u32 index, u
On 03/19/2012 05:56 PM, Michael S. Tsirkin wrote:
> Currently virtio-pci is specified so that configuration of the device is
> done through a PCI IO space (via BAR 0 of the virtual PCI device).
> However, Linux guests happen to use ioread/iowrite/iomap primitives
> for access, and these work unifor
On Mon, Mar 19, 2012 at 07:58:12PM +0200, Avi Kivity wrote:
> On 03/19/2012 05:56 PM, Michael S. Tsirkin wrote:
> > Currently virtio-pci is specified so that configuration of the device is
> > done through a PCI IO space (via BAR 0 of the virtual PCI device).
> > However, Linux guests happen to use
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently virtio-pci is specified so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual PCI device).
However, Linux guests happen to use ioread/iowrite/iomap primitives
for access, and these work uniformly ac
-Original Message-
From: Sever Apostu
Sent: Sunday, March 18, 2012 10:27 PM
To: kvm@vger.kernel.org
Subject: KVM inside Oracle VM
Hi,
I'm planning on building an Oracle VM machine with KVM inside (three KVM
machines inside one Oracle VM machine). The trouble is I have yet to find any
r
Il 19/03/2012 20:29, Sever Apostu ha scritto:
> Any chance anyone has any feedback about KVM installed inside a Xen guest ?
It's really a Xen question more than a KVM question.
Performance and stability will probably suffer.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Monday, March 19, 2012 10:01 PM
To: Sever Apostu
Cc: kvm@vger.kernel.org
Subject: Re: KVM inside Oracle VM
Il 19/03/2012 20:29, Sever Apostu ha scritto:
> Any chance anyone has any feedback about KVM installed insid
Currently virtio-pci is specified so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual PCI device).
However, Linux guests happen to use ioread/iowrite/iomap primitives
for access, and these work uniformly across memory/io BARs.
While PCI IO accesses are fast
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
> On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
> >Currently virtio-pci is specified so that configuration of the device is
> >done through a PCI IO space (via BAR 0 of the virtual PCI device).
> >However, Linux guests happen to u
On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently virtio-pci is specified so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual PCI
On Mon, Mar 19, 2012 at 04:07:45PM -0500, Anthony Liguori wrote:
> On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
> >On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
> >>On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
> >>>Currently virtio-pci is specified so that configuration
On Mon, Mar 19, 2012 at 04:07:45PM -0500, Anthony Liguori wrote:
> On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
> >On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
> >>On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
> >>>Currently virtio-pci is specified so that configuration
On 03/19/2012 04:29 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 04:07:45PM -0500, Anthony Liguori wrote:
On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently vir
Kernel 3.3 is released, and so is kvm-kmod-3.3 now as well. The
package is available from
http://sourceforge.net/projects/kvm/files/kvm-kmod/3.3/kvm-kmod-3.3.tar.bz2/download
See [1] for further details on kvm-kmod.
KVM changes since kvm-kmod-3.2:
- more MMU/MMIO speedup
- CPU feature whitelis
From: John Fastabend
Date: Sun, 18 Mar 2012 23:51:45 -0700
> This series is a follow up to this thread:
>
> http://www.spinics.net/lists/netdev/msg191360.html
Can the interested parties please review this series?
I'm willing to apply this right now if it looks OK, but if
it needs more revision
On Sun, 2012-03-18 at 23:52 -0700, Fastabend, John R wrote:
> This allows RAR table updates while in promiscuous. With
> SR-IOV enabled it is valuable to allow the RAR table to
> be updated even when in promisc mode to configure forwarding
>
> Signed-off-by: John Fastabend
> ---
>
> drivers/net
On Sun, 2012-03-18 at 23:52 -0700, Fastabend, John R wrote:
> Enable FDB ops on ixgbe when in SR-IOV mode.
>
> Signed-off-by: John Fastabend
> ---
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 59
> +
> 1 files changed, 59 insertions(+), 0 deletions(-)
Acked-by
On Mon, 19 Mar 2012 18:38:08 -0400 (EDT)
David Miller wrote:
> From: John Fastabend
> Date: Sun, 18 Mar 2012 23:51:45 -0700
>
> > This series is a follow up to this thread:
> >
> > http://www.spinics.net/lists/netdev/msg191360.html
>
> Can the interested parties please review this series?
>
On Mon, 19 Mar 2012 17:13:06 -0500, Anthony Liguori
wrote:
> > Maybe just make this a hidden option like x-miio?
>
> x-violate-the-virtio-spec-to-trick-old-linux-drivers-into-working-on-power?
"To configure the device, we use the first I/O region of the PCI
device."
Meh, it does sound a little
On 3/19/2012 3:55 PM, Stephen Hemminger wrote:
> On Mon, 19 Mar 2012 18:38:08 -0400 (EDT)
> David Miller wrote:
>
>> From: John Fastabend
>> Date: Sun, 18 Mar 2012 23:51:45 -0700
>>
>>> This series is a follow up to this thread:
>>>
>>> http://www.spinics.net/lists/netdev/msg191360.html
>>
>> Ca
From: John Fastabend
Date: Mon, 19 Mar 2012 17:27:00 -0700
> Dave, its probably fine to push this to 3.5 then.
Fair enough.
--
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/major
On 03/19/2012 06:52 PM, Rusty Russell wrote:
On Mon, 19 Mar 2012 17:13:06 -0500, Anthony Liguori
wrote:
Maybe just make this a hidden option like x-miio?
x-violate-the-virtio-spec-to-trick-old-linux-drivers-into-working-on-power?
"To configure the device, we use the first I/O region of the
On 3/19/2012 5:35 PM, David Miller wrote:
> From: John Fastabend
> Date: Mon, 19 Mar 2012 17:27:00 -0700
>
>> Dave, its probably fine to push this to 3.5 then.
>
> Fair enough.
Stephen, please let me know if you see any issues though
because without these we have no way to forward packets
corre
On Mon, 19 Mar 2012 19:49:50 -0700
John Fastabend wrote:
> On 3/19/2012 5:35 PM, David Miller wrote:
> > From: John Fastabend
> > Date: Mon, 19 Mar 2012 17:27:00 -0700
> >
> >> Dave, its probably fine to push this to 3.5 then.
> >
> > Fair enough.
>
> Stephen, please let me know if you see an
On Thu, 15 Mar 2012 15:46:31 +0200
Avi Kivity wrote:
> You can look at what's happening by doing
>
> perf record -a -f
> perf report
>
> using the TUI, select 'annotate rmap_get_next'
>
> You should see where the time is spent.
>
Since the default sampling rate was not enough to get cons
65 matches
Mail list logo
