On Tue, Mar 18, 2014 at 8:10 PM, Stephen Hemminger
wrote:
> On Wed, 12 Mar 2014 20:15:25 -0700
> "Luis R. Rodriguez" wrote:
>
>> As it is now if you add create a bridge it gets started
>> with a random MAC address and if you then add a net_device
>> as a slave but later kick it out you end up wit
On 03/18/2014 04:14 AM, Paolo Bonzini wrote:
Il 17/03/2014 20:05, Konrad Rzeszutek Wilk ha scritto:
> Measurements were done by Gleb for two guests running 2.6.32 with 16
> vcpus each, on a 16-core system. One guest ran with unfair locks,
> one guest ran with fair locks. Two kernel compilation
On Wed, 12 Mar 2014 20:15:25 -0700
"Luis R. Rodriguez" wrote:
> As it is now if you add create a bridge it gets started
> with a random MAC address and if you then add a net_device
> as a slave but later kick it out you end up with a zero
> MAC address. Instead preserve the original random MAC
>
On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
wrote:
> (2014/03/19 9:50), Luis R. Rodriguez wrote:
>> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
>> wrote:
>>> nit,
>>> If the last detached port happens to have the same addr as
>>> random_init_addr, this seems to call br_stp_change_bridge
(2014/03/19 9:50), Luis R. Rodriguez wrote:
> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
> wrote:
>> nit,
>> If the last detached port happens to have the same addr as
>> random_init_addr, this seems to call br_stp_change_bridge_id() even
>> though bridge_id is not changed.
>
> Ah good poin
On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
wrote:
> nit,
> If the last detached port happens to have the same addr as
> random_init_addr, this seems to call br_stp_change_bridge_id() even
> though bridge_id is not changed.
Ah good point.
> Shouldn't the assignment of random_init_addr be do
(2014/03/13 12:15), Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> As it is now if you add create a bridge it gets started
> with a random MAC address and if you then add a net_device
> as a slave but later kick it out you end up with a zero
> MAC address. Instead preserve the original
On Tue, 2014-03-18 at 09:32 +0800, Gavin Shan wrote:
> On Mon, Mar 17, 2014 at 04:16:22PM -0600, Alex Williamson wrote:
> >On Mon, 2014-03-10 at 13:46 +0800, Gavin Shan wrote:
> >> The problem is specific to the case of BIST reset issued to IPR
> >> adapter on the guest side. The IPR driver calls p
On 18 March 2014 03:23, Srivatsa S. Bhat
wrote:
> On 03/15/2014 12:40 AM, Christoffer Dall wrote:
>> On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
>>> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
> Su
On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote:
> On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez wrote:
> > On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
> >> On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
> >> wrote:
> >> > spin_unlock_bh(&
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well.
Signed-off-by: Zoltan Kiss
---
net/openvswitch/datapath.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/lin
On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez wrote:
> On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
>> On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
>> wrote:
>> > spin_unlock_bh(&p->br->lock);
>> > + if (changed)
>> > +
On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
wrote:
> Here's a few fixes I've been carrying around. I've now tested them
> on as many systems / environments as I can. They should be ready.
>
> Luis R. Rodriguez (3):
> bridge: preserve random init MAC address
> bridge: trigger a bridge ca
On Tue, 18 Mar 2014 17:13:04 +0100
Paolo Bonzini wrote:
> Il 17/03/2014 19:12, Cornelia Huck ha scritto:
> > if (!qemu_opt_get_bool(qemu_get_machine_opts(), "kernel_irqchip",
> > true) ||
> > -!kvm_check_extension(s, KVM_CAP_IRQCHIP)) {
> > +(!kvm_check_extension(s, KVM_CAP_
On Tue, 18 Mar 2014 17:10:33 +0100
Paolo Bonzini wrote:
> Il 17/03/2014 19:11, Cornelia Huck ha scritto:
> > +static KVMS390FLICState *s390_get_flic(void)
> > +{
> > +ObjectProperty *op = object_property_find(qdev_get_machine(),
> > + "s390-flic",
Il 17/03/2014 22:55, Christian Borntraeger ha scritto:
> Signed-off-by: Cornelia Huck
Do you still have the lockdep message somewhere?
Looking at the patch and the description this makes sense. Even without
irqfd for s390:
Reviewed-by: Christian Borntraeger
Paolo, maybe this patch can go in i
Il 17/03/2014 19:12, Cornelia Huck ha scritto:
if (!qemu_opt_get_bool(qemu_get_machine_opts(), "kernel_irqchip", true) ||
-!kvm_check_extension(s, KVM_CAP_IRQCHIP)) {
+(!kvm_check_extension(s, KVM_CAP_IRQCHIP) &&
+ kvm_enable_cap_vm(s, KVM_CAP_S390_IRQCHIP))) {
Plea
Il 17/03/2014 19:11, Cornelia Huck ha scritto:
+static KVMS390FLICState *s390_get_flic(void)
+{
+ObjectProperty *op = object_property_find(qdev_get_machine(),
+ "s390-flic", NULL);
+
+if (op) {
+return op->opaque;
+} else {
+
Il 17/03/2014 19:11, Cornelia Huck ha scritto:
The maximum number for irq routes is currently 1024, which is a bit on
the small size for s390: We support up to 4 x 64k virtual devices with
up to 64 queues, and we need one route for each of the queues if we want
to operate it via irqfd.
Let's bum
Il 18/03/2014 16:10, Jan Kiszka ha scritto:
> +void kvm_ioapic_inject_all(struct kvm_ioapic *ioapic, unsigned long irr)
static? (Didn't the compiler bark at you?)
I re-checked and it didn't indeed. Fixed this locally.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
On 2014-03-18 15:54, Paolo Bonzini wrote:
> After the previous patches, an interrupt whose bit is set in the IRR
> register will never be in the LAPIC's IRR and has never been injected
> on the migration source. So inject it on the destination.
>
> This fixes migration of Windows guests without H
On Tue, 2014-03-18 at 14:02 +0300, Dennis Mungai wrote:
> Also, on the same note, do Intel processors from Lynnfield (2009 Core i7s)
> and Arrandale (2010 Mobile Intel Core processors ) that advertise VT-d
> support handle these advanced features?
You would need to check the capability registers o
Commonize the handling of masking, which was absent for kvm_ioapic_set_irq.
Setting remote_irr does not need a separate function either, and merging
the two functions avoids confusion.
Signed-off-by: Paolo Bonzini
---
virt/kvm/ioapic.c | 29 +
1 file changed, 9 insert
We will reuse it to process a nonzero IRR that is passed to KVM_SET_IRQCHIP.
Signed-off-by: Paolo Bonzini
---
virt/kvm/ioapic.c | 63 ++-
1 file changed, 39 insertions(+), 24 deletions(-)
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
inde
This ensures that IRR bits are set in the KVM_GET_IRQCHIP result only if
the interrupt is still sitting in the IOAPIC. After the next patches, it
avoids spurious reinjection of the interrupt when KVM_SET_IRQCHIP is
called.
Signed-off-by: Paolo Bonzini
---
virt/kvm/ioapic.c | 3 +++
1 file chang
After the previous patches, an interrupt whose bit is set in the IRR
register will never be in the LAPIC's IRR and has never been injected
on the migration source. So inject it on the destination.
This fixes migration of Windows guests without HPET (they use the RTC
to trigger the scheduler tick,
Unlike the old qemu-kvm, which really never did that, with new QEMU
it is for some reason somewhat likely to migrate a VM with a nonzero
IRR in the ioapic. In the case of ISA edge-triggered interrupts,
this represents an interrupt that has not left the IOAPIC, which would
be okay but it is not han
On Tue, 2014-03-18 at 10:24 +, Varun Sethi wrote:
> Hi Alex,
> Would it make sense, to link the iommu group to its corresponding
> hardware iommu block's capabilities? This could be done if we can
> determine the iommu device corresponding to the iommu group during bus
> probe. With this we won
Juan Quintela wrote:
> Hi
>
> Please, send any topic that you are interested in covering.
>
> Thanks, Juan.
Sorry for being late.
No topics -> No call
(I will learn daylight savings at some point :-())
Later, Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
Please is your email really active?
--
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
Il 17/03/2014 18:38, H. Peter Anvin ha scritto:
I'm not sure what you mean with "valid real mode selectors"; the normal
case in big real mode is that either CS = SS = 0 or CS = SS = .
I mean "valid according to the VMX spec" for running in vm86 mode: base
= selector << 4, limit = 0x, acces
Hi Alex,
Would it make sense, to link the iommu group to its corresponding hardware
iommu block's capabilities? This could be done if we can determine the iommu
device corresponding to the iommu group during bus probe. With this we won't
have to wait till device attach to determine the domain ca
On 03/15/2014 12:40 AM, Christoffer Dall wrote:
> On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
>> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
>>> On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
Subsystems that want to register CPU hotplug callbacks, a
On Mon, 17 Mar 2014 22:55:49 +0100
Christian Borntraeger wrote:
> On 17/03/14 19:11, Cornelia Huck wrote:
> > When registering a new irqfd, we call its ->poll method to collect any
> > event that might have previously been pending so that we can trigger it.
> > This is done under the kvm->irqfds.
Linus,
The following changes since commit b73117c49364551ff789db7c424a115ac5b77850:
Merge branch 'kvm-ppc-next' of git://github.com/agraf/linux-2.6 into
kvm-queue (2014-01-29 18:29:01 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linu
On Tue, 18 Mar 2014 09:11:19 +0100
Heiko Carstens wrote:
> On Mon, Mar 17, 2014 at 07:11:37PM +0100, Cornelia Huck wrote:
> > Add a new interface to register/deregister sources of adapter interrupts
> > identified by an unique id via the flic. Adapters may also be maskable
> > and carry a list of
Il 17/03/2014 19:54, Peter Zijlstra ha scritto:
On Mon, Mar 17, 2014 at 01:44:34PM -0400, Waiman Long wrote:
The PV ticketlock code was designed to handle lock holder preemption by
redirecting CPU resources in a preempted guest to another guest that can
better use it and then return the preempte
Il 17/03/2014 20:05, Konrad Rzeszutek Wilk ha scritto:
> Measurements were done by Gleb for two guests running 2.6.32 with 16
> vcpus each, on a 16-core system. One guest ran with unfair locks,
> one guest ran with fair locks. Two kernel compilations ("time make
And when you say fair locks are
On Mon, Mar 17, 2014 at 07:11:37PM +0100, Cornelia Huck wrote:
> Add a new interface to register/deregister sources of adapter interrupts
> identified by an unique id via the flic. Adapters may also be maskable
> and carry a list of pinned pages.
>
> These adapters will be used by irq routing late
On Mon, 17 Mar 2014 18:24:08 +
Peter Maydell wrote:
> On 17 March 2014 18:11, Cornelia Huck wrote:
> > Per-vm capability enablement, adapter interrupt sources, irq routing on
> > s390.
> >
> > Reviewed-by: Thomas Huth
> > Signed-off-by: Cornelia Huck
>
> This is an RFC patchset, since th
40 matches
Mail list logo
