Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1287185 > unrolled thread

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

Started by"Wu, Feng" <feng.wu@intel.com>
First post2015-12-09 09:30 +0100
Last post2015-12-15 03:00 +0100
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d  posted-interrupts "Wu, Feng" <feng.wu@intel.com> - 2015-12-09 09:30 +0100
    Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d  posted-interrupts Radim Krčmář <rkrcmar@redhat.com> - 2015-12-09 16:00 +0100
      RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d  posted-interrupts "Wu, Feng" <feng.wu@intel.com> - 2015-12-10 03:00 +0100
        Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d  posted-interrupts Radim Krcmár <rkrcmar@redhat.com> - 2015-12-11 15:40 +0100
          RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d  posted-interrupts "Wu, Feng" <feng.wu@intel.com> - 2015-12-15 03:00 +0100

#1287185 — RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

From"Wu, Feng" <feng.wu@intel.com>
Date2015-12-09 09:30 +0100
SubjectRE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts
Message-ID<qDIim-5Rn-1@gated-at.bofh.it>
Hi Radim,

> -----Original Message-----
> From: Radim Krčmář [mailto:rkrcmar@redhat.com]
> Sent: Tuesday, November 17, 2015 3:03 AM
> To: Wu, Feng <feng.wu@intel.com>
> Cc: pbonzini@redhat.com; kvm@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-
> interrupts
> 
> 2015-11-09 10:46+0800, Feng Wu:
> > Use vector-hashing to handle lowest-priority interrupts for
> > posted-interrupts. As an example, modern Intel CPUs use this
> > method to handle lowest-priority interrupts.
> 
> (I don't think it's a good idea that the algorithm differs from non-PI
>  lowest priority delivery.  I'd make them both vector-hashing, which
>  would be "fun" to explain to people expecting round robin ...)
> 
> > Signed-off-by: Feng Wu <feng.wu@intel.com>
> > ---
> > diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> > +/*
> > + * This routine handles lowest-priority interrupts using vector-hashing
> > + * mechanism. As an example, modern Intel CPUs use this method to handle
> > + * lowest-priority interrupts.
> > + *
> > + * Here is the details about the vector-hashing mechanism:
> > + * 1. For lowest-priority interrupts, store all the possible destination
> > + *    vCPUs in an array.
> > + * 2. Use "guest vector % max number of destination vCPUs" to find the right
> > + *    destination vCPU in the array for the lowest-priority interrupt.
> > + */
> 
> (Is Skylake i7-6700 a modern Intel CPU?
>  I didn't manage to get hashing ... all interrupts always went to the
>  lowest APIC ID in the set :/
>  Is there a simple way to verify the algorithm?)
> 
> > +struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
> > +					      struct kvm_lapic_irq *irq)
> > +
> > +{
> > +	unsigned long dest_vcpu_bitmap[BITS_TO_LONGS(KVM_MAX_VCPUS)];
> > +	unsigned int dest_vcpus = 0;
> > +	struct kvm_vcpu *vcpu;
> > +	unsigned int i, mod, idx = 0;
> > +
> > +	vcpu = kvm_intr_vector_hashing_dest_fast(kvm, irq);
> > +	if (vcpu)
> > +		return vcpu;
> 
> I think the rest of this function shouldn't be implemented:
>  - Shorthands are only for IPIs and hence don't need to be handled,
>  - Lowest priority physical broadcast is not supported,
>  - Lowest priority cluster logical broadcast is not supported,
>  - No point in optimizing mixed xAPIC and x2APIC mode,

I read your comments again, and don't quite understand why we
don't need PI optimization for mixed xAPIC and x2APIC mode.

BTW, can we have mixed flat and cluster mode?

Thanks,
Feng

>  - The rest is handled by kvm_intr_vector_hashing_dest_fast().
>    (Even lowest priority flat logical "broadcast".)
>  - We do the work twice when vcpu == NULL means that there is no
>    matching destination.
> 
> Is there a valid case that can be resolved by going through all vcpus?
> 
> > +
> > +	memset(dest_vcpu_bitmap, 0, sizeof(dest_vcpu_bitmap));
> > +
> > +	kvm_for_each_vcpu(i, vcpu, kvm) {
> > +		if (!kvm_apic_present(vcpu))
> > +			continue;
> > +
> > +		if (!kvm_apic_match_dest(vcpu, NULL, irq->shorthand,
> > +					irq->dest_id, irq->dest_mode))
> > +			continue;
> > +
> > +		__set_bit(vcpu->vcpu_id, dest_vcpu_bitmap);
> > +		dest_vcpus++;
> > +	}
> > +
> > +	if (dest_vcpus == 0)
> > +		return NULL;
> > +
> > +	mod = irq->vector % dest_vcpus;
> > +
> > +	for (i = 0; i <= mod; i++) {
> > +		idx = find_next_bit(dest_vcpu_bitmap, KVM_MAX_VCPUS, idx) +
> 1;
> > +		BUG_ON(idx >= KVM_MAX_VCPUS);
> > +	}
> > +
> > +	return kvm_get_vcpu(kvm, idx - 1);
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_intr_vector_hashing_dest);
> > +
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > @@ -816,6 +816,63 @@ out:
> > +struct kvm_vcpu *kvm_intr_vector_hashing_dest_fast(struct kvm *kvm,
> > +						   struct kvm_lapic_irq *irq)
> 
> We now have three very similar functions :(
> 
>   kvm_irq_delivery_to_apic_fast
>   kvm_intr_is_single_vcpu_fast
>   kvm_intr_vector_hashing_dest_fast
> 
> By utilizing the gcc optimizer, they can be merged without introducing
> many instructions to the hot path, kvm_irq_delivery_to_apic_fast.
> (I would eventually do it, so you can save time by ignoring this.)
> 
> Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1287539

FromRadim Krčmář <rkrcmar@redhat.com>
Date2015-12-09 16:00 +0100
Message-ID<qDOnM-1h9-13@gated-at.bofh.it>
In reply to#1287185
2015-12-09 08:19+0000, Wu, Feng:
>> -----Original Message-----
>> From: Radim Krčmář [mailto:rkrcmar@redhat.com]
>> Sent: Tuesday, November 17, 2015 3:03 AM
>> To: Wu, Feng <feng.wu@intel.com>
>> Cc: pbonzini@redhat.com; kvm@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-
>> interrupts
>> 
>> 2015-11-09 10:46+0800, Feng Wu:
>> > +struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
>> > +					      struct kvm_lapic_irq *irq)
>> > +
>> > +{
>> > +	unsigned long dest_vcpu_bitmap[BITS_TO_LONGS(KVM_MAX_VCPUS)];
>> > +	unsigned int dest_vcpus = 0;
>> > +	struct kvm_vcpu *vcpu;
>> > +	unsigned int i, mod, idx = 0;
>> > +
>> > +	vcpu = kvm_intr_vector_hashing_dest_fast(kvm, irq);
>> > +	if (vcpu)
>> > +		return vcpu;
>> 
>> I think the rest of this function shouldn't be implemented:
>>  - Shorthands are only for IPIs and hence don't need to be handled,
>>  - Lowest priority physical broadcast is not supported,
>>  - Lowest priority cluster logical broadcast is not supported,
>>  - No point in optimizing mixed xAPIC and x2APIC mode,
> 
> I read your comments again, and don't quite understand why we
> don't need PI optimization for mixed xAPIC and x2APIC mode.

There shouldn't be a non-hobbyist operating system that uses mixed mode,
so the optimization would practically be dead code as all other cases
are handled by kvm_intr_vector_hashing_dest_fast().

I think that having extra code would bring problems in the future -- we
need to take care of it when refactoring KVM's APIC and we should also
write a unit-test for this otherwise dead path.  I don't think that the
benefit for guests would ever balance those efforts.

(Physical xAPIC+x2APIC mode is still somewhat reasonable and xAPIC CPUs
 start with LDR=0, which means that operating system doesn't need to
 utilize mixed mode, as defined by KVM, when switching to x2APIC.)

> BTW, can we have mixed flat and cluster mode?

Yes, KVM recognizes that mixed mode, but luckily, there are severe
limitations.

Notes below SDM section 10.6.2.2:
  All processors that have their APIC software enabled (using the
  spurious vector enable/disable bit) must have their DFRs (Destination
  Format Registers) programmed identically.

I hope there isn't a human that would use it in good faith.

(Only NMI/SMI/INIT/SIPI are delivered in software disabled mode and if
 the system uses cluster xAPIC, OS should set DFR before LDR, which
 doesn't trigger mixed mode either.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1288127

From"Wu, Feng" <feng.wu@intel.com>
Date2015-12-10 03:00 +0100
Message-ID<qDYGu-7Sr-5@gated-at.bofh.it>
In reply to#1287539
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFkaW0gS3LEjW3DocWZ
IFttYWlsdG86cmtyY21hckByZWRoYXQuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVy
IDksIDIwMTUgMTA6NTQgUE0NCj4gVG86IFd1LCBGZW5nIDxmZW5nLnd1QGludGVsLmNvbT4NCj4g
Q2M6IHBib256aW5pQHJlZGhhdC5jb207IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5l
bEB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gS1ZNOiB4ODY6IEFkZCBs
b3dlc3QtcHJpb3JpdHkgc3VwcG9ydCBmb3IgdnQtZCBwb3N0ZWQtDQo+IGludGVycnVwdHMNCj4g
DQo+IDIwMTUtMTItMDkgMDg6MTkrMDAwMCwgV3UsIEZlbmc6DQo+ID4+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFJhZGltIEtyxI1tw6HFmSBbbWFpbHRvOnJrcmNtYXJA
cmVkaGF0LmNvbV0NCj4gPj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTcsIDIwMTUgMzowMyBB
TQ0KPiA+PiBUbzogV3UsIEZlbmcgPGZlbmcud3VAaW50ZWwuY29tPg0KPiA+PiBDYzogcGJvbnpp
bmlAcmVkaGF0LmNvbTsga3ZtQHZnZXIua2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSF0gS1ZNOiB4ODY6IEFkZCBsb3dl
c3QtcHJpb3JpdHkgc3VwcG9ydCBmb3IgdnQtZCBwb3N0ZWQtDQo+ID4+IGludGVycnVwdHMNCj4g
Pj4NCj4gPj4gMjAxNS0xMS0wOSAxMDo0NiswODAwLCBGZW5nIFd1Og0KPiA+PiA+ICtzdHJ1Y3Qg
a3ZtX3ZjcHUgKmt2bV9pbnRyX3ZlY3Rvcl9oYXNoaW5nX2Rlc3Qoc3RydWN0IGt2bSAqa3ZtLA0K
PiA+PiA+ICsJCQkJCSAgICAgIHN0cnVjdCBrdm1fbGFwaWNfaXJxICppcnEpDQo+ID4+ID4gKw0K
PiA+PiA+ICt7DQo+ID4+ID4gKwl1bnNpZ25lZCBsb25nIGRlc3RfdmNwdV9iaXRtYXBbQklUU19U
T19MT05HUyhLVk1fTUFYX1ZDUFVTKV07DQo+ID4+ID4gKwl1bnNpZ25lZCBpbnQgZGVzdF92Y3B1
cyA9IDA7DQo+ID4+ID4gKwlzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHU7DQo+ID4+ID4gKwl1bnNpZ25l
ZCBpbnQgaSwgbW9kLCBpZHggPSAwOw0KPiA+PiA+ICsNCj4gPj4gPiArCXZjcHUgPSBrdm1faW50
cl92ZWN0b3JfaGFzaGluZ19kZXN0X2Zhc3Qoa3ZtLCBpcnEpOw0KPiA+PiA+ICsJaWYgKHZjcHUp
DQo+ID4+ID4gKwkJcmV0dXJuIHZjcHU7DQo+ID4+DQo+ID4+IEkgdGhpbmsgdGhlIHJlc3Qgb2Yg
dGhpcyBmdW5jdGlvbiBzaG91bGRuJ3QgYmUgaW1wbGVtZW50ZWQ6DQo+ID4+ICAtIFNob3J0aGFu
ZHMgYXJlIG9ubHkgZm9yIElQSXMgYW5kIGhlbmNlIGRvbid0IG5lZWQgdG8gYmUgaGFuZGxlZCwN
Cj4gPj4gIC0gTG93ZXN0IHByaW9yaXR5IHBoeXNpY2FsIGJyb2FkY2FzdCBpcyBub3Qgc3VwcG9y
dGVkLA0KPiA+PiAgLSBMb3dlc3QgcHJpb3JpdHkgY2x1c3RlciBsb2dpY2FsIGJyb2FkY2FzdCBp
cyBub3Qgc3VwcG9ydGVkLA0KPiA+PiAgLSBObyBwb2ludCBpbiBvcHRpbWl6aW5nIG1peGVkIHhB
UElDIGFuZCB4MkFQSUMgbW9kZSwNCj4gPg0KPiA+IEkgcmVhZCB5b3VyIGNvbW1lbnRzIGFnYWlu
LCBhbmQgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCB3aHkgd2UNCj4gPiBkb24ndCBuZWVkIFBJIG9w
dGltaXphdGlvbiBmb3IgbWl4ZWQgeEFQSUMgYW5kIHgyQVBJQyBtb2RlLg0KPiANCj4gVGhlcmUg
c2hvdWxkbid0IGJlIGEgbm9uLWhvYmJ5aXN0IG9wZXJhdGluZyBzeXN0ZW0gdGhhdCB1c2VzIG1p
eGVkIG1vZGUsDQo+IHNvIHRoZSBvcHRpbWl6YXRpb24gd291bGQgcHJhY3RpY2FsbHkgYmUgZGVh
ZCBjb2RlIGFzIGFsbCBvdGhlciBjYXNlcw0KPiBhcmUgaGFuZGxlZCBieSBrdm1faW50cl92ZWN0
b3JfaGFzaGluZ19kZXN0X2Zhc3QoKS4NCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGVsYWJvcmF0
aW9uIQ0KDQo+IA0KPiBJIHRoaW5rIHRoYXQgaGF2aW5nIGV4dHJhIGNvZGUgd291bGQgYnJpbmcg
cHJvYmxlbXMgaW4gdGhlIGZ1dHVyZSAtLSB3ZQ0KPiBuZWVkIHRvIHRha2UgY2FyZSBvZiBpdCB3
aGVuIHJlZmFjdG9yaW5nIEtWTSdzIEFQSUMgYW5kIHdlIHNob3VsZCBhbHNvDQo+IHdyaXRlIGEg
dW5pdC10ZXN0IGZvciB0aGlzIG90aGVyd2lzZSBkZWFkIHBhdGguICBJIGRvbid0IHRoaW5rIHRo
YXQgdGhlDQo+IGJlbmVmaXQgZm9yIGd1ZXN0cyB3b3VsZCBldmVyIGJhbGFuY2UgdGhvc2UgZWZm
b3J0cy4NCj4gDQo+IChQaHlzaWNhbCB4QVBJQyt4MkFQSUMgbW9kZSBpcyBzdGlsbCBzb21ld2hh
dCByZWFzb25hYmxlIGFuZCB4QVBJQyBDUFVzDQo+ICBzdGFydCB3aXRoIExEUj0wLCB3aGljaCBt
ZWFucyB0aGF0IG9wZXJhdGluZyBzeXN0ZW0gZG9lc24ndCBuZWVkIHRvDQo+ICB1dGlsaXplIG1p
eGVkIG1vZGUsIGFzIGRlZmluZWQgYnkgS1ZNLCB3aGVuIHN3aXRjaGluZyB0byB4MkFQSUMuKQ0K
DQpJIHRoaW5rIHlvdSBtZWFuIFBoeXNpY2FsIHhBUElDK1BoeXNpY2FsIHgyQVBJQyBtb2RlLCBy
aWdodD8gRm9yIHBoeXNpY2FsDQptb2RlLCB3ZSBkb24ndCB1c2UgTERSIGluIGFueSBjYXNlLCBk
byB3ZT8gU28gaW4gcGh5c2ljYWwgbW9kZSwgd2Ugb25seQ0KdXNlIHRoZSBBUElDIElELCB0aGF0
IGlzIHdoeSB0aGV5IGNhbiBiZSBtaXhlZCwgaXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0K
VGhhbmtzIGEgbG90IQ0KDQo+IA0KPiA+IEJUVywgY2FuIHdlIGhhdmUgbWl4ZWQgZmxhdCBhbmQg
Y2x1c3RlciBtb2RlPw0KPiANCj4gWWVzLCBLVk0gcmVjb2duaXplcyB0aGF0IG1peGVkIG1vZGUs
IGJ1dCBsdWNraWx5LCB0aGVyZSBhcmUgc2V2ZXJlDQo+IGxpbWl0YXRpb25zLg0KPiANCj4gTm90
ZXMgYmVsb3cgU0RNIHNlY3Rpb24gMTAuNi4yLjI6DQo+ICAgQWxsIHByb2Nlc3NvcnMgdGhhdCBo
YXZlIHRoZWlyIEFQSUMgc29mdHdhcmUgZW5hYmxlZCAodXNpbmcgdGhlDQo+ICAgc3B1cmlvdXMg
dmVjdG9yIGVuYWJsZS9kaXNhYmxlIGJpdCkgbXVzdCBoYXZlIHRoZWlyIERGUnMgKERlc3RpbmF0
aW9uDQo+ICAgRm9ybWF0IFJlZ2lzdGVycykgcHJvZ3JhbW1lZCBpZGVudGljYWxseS4NCg0KVGhh
bmtzIGZvciBwb2ludGluZyB0aGlzIG91dCwgZ29vZCB0byBrbm93IGl0IQ0KDQo+IA0KPiBJIGhv
cGUgdGhlcmUgaXNuJ3QgYSBodW1hbiB0aGF0IHdvdWxkIHVzZSBpdCBpbiBnb29kIGZhaXRoLg0K
PiANCj4gKE9ubHkgTk1JL1NNSS9JTklUL1NJUEkgYXJlIGRlbGl2ZXJlZCBpbiBzb2Z0d2FyZSBk
aXNhYmxlZCBtb2RlIGFuZCBpZg0KPiAgdGhlIHN5c3RlbSB1c2VzIGNsdXN0ZXIgeEFQSUMsIE9T
IHNob3VsZCBzZXQgREZSIGJlZm9yZSBMRFIsIHdoaWNoDQo+ICBkb2Vzbid0IHRyaWdnZXIgbWl4
ZWQgbW9kZSBlaXRoZXIuKQ0KDQpKdXN0IGN1cmlvdXMsIGlmIHRoZSBBUElDIGlzIHNvZnR3YXJl
IGRpc2FibGVkIGFuZCBpdCBpcyBpbiB4QVBJQyBtb2RlLiBPUyBzZXRzDQpkaWZmZXJlbnQgdmFs
dWUgZm9yIERGUiBmb3IgZGlmZmVyZW50IEFQSUNzLCB0aGVuIHdoZW4gT1Mgc2V0cyBMRFIsIEtW
TSBjYW4NCnRyaWdnZXIgbWl4ZWQgZmxhdCBhbmQgY2x1c3RlciBtb2RlLCByaWdodD8NCg0KVGhh
bmtzLA0KRmVuZw0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289634

FromRadim Krcmár <rkrcmar@redhat.com>
Date2015-12-11 15:40 +0100
Message-ID<qEx1v-5JU-7@gated-at.bofh.it>
In reply to#1288127
2015-12-10 01:52+0000, Wu, Feng:
>> From: Radim Krčmář [mailto:rkrcmar@redhat.com]
>> (Physical xAPIC+x2APIC mode is still somewhat reasonable and xAPIC CPUs
>>  start with LDR=0, which means that operating system doesn't need to
>>  utilize mixed mode, as defined by KVM, when switching to x2APIC.)
> 
> I think you mean Physical xAPIC+Physical x2APIC mode, right? For physical
> mode, we don't use LDR in any case, do we? So in physical mode, we only
> use the APIC ID, that is why they can be mixed, is my understanding correct?

Yes.  (Technically, physical and logical addressing is always active in
APIC, but xAPIC must have nonzero LDR to accept logical interrupts[1].)
If all xAPIC LDRs are zero, KVM doesn't enter a "mixed mode" even if
some are xAPIC and some x2APIC [2].

1: Real LAPICs probably do not accept broadcasts on APICs where LDR=0,
   KVM LAPICs do, but lowest priority broadcast is not allowed anyway,
   so PI doesn't care.

2: KVM allows OS-writeable APIC ID, which complicates things and real
   hardware probably doesn't allow it because of that ... we'd be saner
   with RO APIC ID, but it's not that bad.  (And no major OS does it :])

>>  the system uses cluster xAPIC, OS should set DFR before LDR, which
>>  doesn't trigger mixed mode either.)
> 
> Just curious, if the APIC is software disabled and it is in xAPIC mode. OS sets
> different value for DFR for different APICs, then when OS sets LDR, KVM can
> trigger mixed flat and cluster mode, right?

Exactly.
APICs with zeroed LDR are ignored, so KVM will use the slow-path for
delivery (= trigger mixed mode) at the moment the first APIC with
different DFR is configured.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291768

From"Wu, Feng" <feng.wu@intel.com>
Date2015-12-15 03:00 +0100
Message-ID<qFN4d-5Oz-3@gated-at.bofh.it>
In reply to#1289634
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbToga3ZtLW93bmVyQHZnZXIu
a2VybmVsLm9yZyBbbWFpbHRvOmt2bS1vd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uDQo+IEJlaGFs
ZiBPZiBSYWRpbSBLcmNtw6FyDQo+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTEsIDIwMTUgMTA6
MzggUE0NCj4gVG86IFd1LCBGZW5nIDxmZW5nLnd1QGludGVsLmNvbT4NCj4gQ2M6IHBib256aW5p
QHJlZGhhdC5jb207IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5l
bC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gS1ZNOiB4ODY6IEFkZCBsb3dlc3QtcHJpb3Jp
dHkgc3VwcG9ydCBmb3IgdnQtZCBwb3N0ZWQtDQo+IGludGVycnVwdHMNCj4gDQo+IDIwMTUtMTIt
MTAgMDE6NTIrMDAwMCwgV3UsIEZlbmc6DQo+ID4+IEZyb206IFJhZGltIEtyxI1tw6HFmSBbbWFp
bHRvOnJrcmNtYXJAcmVkaGF0LmNvbV0NCj4gPj4gKFBoeXNpY2FsIHhBUElDK3gyQVBJQyBtb2Rl
IGlzIHN0aWxsIHNvbWV3aGF0IHJlYXNvbmFibGUgYW5kIHhBUElDIENQVXMNCj4gPj4gIHN0YXJ0
IHdpdGggTERSPTAsIHdoaWNoIG1lYW5zIHRoYXQgb3BlcmF0aW5nIHN5c3RlbSBkb2Vzbid0IG5l
ZWQgdG8NCj4gPj4gIHV0aWxpemUgbWl4ZWQgbW9kZSwgYXMgZGVmaW5lZCBieSBLVk0sIHdoZW4g
c3dpdGNoaW5nIHRvIHgyQVBJQy4pDQo+ID4NCj4gPiBJIHRoaW5rIHlvdSBtZWFuIFBoeXNpY2Fs
IHhBUElDK1BoeXNpY2FsIHgyQVBJQyBtb2RlLCByaWdodD8gRm9yIHBoeXNpY2FsDQo+ID4gbW9k
ZSwgd2UgZG9uJ3QgdXNlIExEUiBpbiBhbnkgY2FzZSwgZG8gd2U/IFNvIGluIHBoeXNpY2FsIG1v
ZGUsIHdlIG9ubHkNCj4gPiB1c2UgdGhlIEFQSUMgSUQsIHRoYXQgaXMgd2h5IHRoZXkgY2FuIGJl
IG1peGVkLCBpcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+IA0KPiBZZXMuICAoVGVjaG5p
Y2FsbHksIHBoeXNpY2FsIGFuZCBsb2dpY2FsIGFkZHJlc3NpbmcgaXMgYWx3YXlzIGFjdGl2ZSBp
bg0KPiBBUElDLCBidXQgeEFQSUMgbXVzdCBoYXZlIG5vbnplcm8gTERSIHRvIGFjY2VwdCBsb2dp
Y2FsIGludGVycnVwdHNbMV0uKQ0KPiBJZiBhbGwgeEFQSUMgTERScyBhcmUgemVybywgS1ZNIGRv
ZXNuJ3QgZW50ZXIgYSAibWl4ZWQgbW9kZSIgZXZlbiBpZg0KPiBzb21lIGFyZSB4QVBJQyBhbmQg
c29tZSB4MkFQSUMgWzJdLg0KPiANCj4gMTogUmVhbCBMQVBJQ3MgcHJvYmFibHkgZG8gbm90IGFj
Y2VwdCBicm9hZGNhc3RzIG9uIEFQSUNzIHdoZXJlIExEUj0wLA0KPiAgICBLVk0gTEFQSUNzIGRv
LCBidXQgbG93ZXN0IHByaW9yaXR5IGJyb2FkY2FzdCBpcyBub3QgYWxsb3dlZCBhbnl3YXksDQo+
ICAgIHNvIFBJIGRvZXNuJ3QgY2FyZS4NCj4gDQo+IDI6IEtWTSBhbGxvd3MgT1Mtd3JpdGVhYmxl
IEFQSUMgSUQsIHdoaWNoIGNvbXBsaWNhdGVzIHRoaW5ncyBhbmQgcmVhbA0KPiAgICBoYXJkd2Fy
ZSBwcm9iYWJseSBkb2Vzbid0IGFsbG93IGl0IGJlY2F1c2Ugb2YgdGhhdCAuLi4gd2UnZCBiZSBz
YW5lcg0KPiAgICB3aXRoIFJPIEFQSUMgSUQsIGJ1dCBpdCdzIG5vdCB0aGF0IGJhZC4gIChBbmQg
bm8gbWFqb3IgT1MgZG9lcyBpdCA6XSkNCj4gDQo+ID4+ICB0aGUgc3lzdGVtIHVzZXMgY2x1c3Rl
ciB4QVBJQywgT1Mgc2hvdWxkIHNldCBERlIgYmVmb3JlIExEUiwgd2hpY2gNCj4gPj4gIGRvZXNu
J3QgdHJpZ2dlciBtaXhlZCBtb2RlIGVpdGhlci4pDQo+ID4NCj4gPiBKdXN0IGN1cmlvdXMsIGlm
IHRoZSBBUElDIGlzIHNvZnR3YXJlIGRpc2FibGVkIGFuZCBpdCBpcyBpbiB4QVBJQyBtb2RlLiBP
UyBzZXRzDQo+ID4gZGlmZmVyZW50IHZhbHVlIGZvciBERlIgZm9yIGRpZmZlcmVudCBBUElDcywg
dGhlbiB3aGVuIE9TIHNldHMgTERSLCBLVk0gY2FuDQo+ID4gdHJpZ2dlciBtaXhlZCBmbGF0IGFu
ZCBjbHVzdGVyIG1vZGUsIHJpZ2h0Pw0KPiANCj4gRXhhY3RseS4NCj4gQVBJQ3Mgd2l0aCB6ZXJv
ZWQgTERSIGFyZSBpZ25vcmVkLCBzbyBLVk0gd2lsbCB1c2UgdGhlIHNsb3ctcGF0aCBmb3INCj4g
ZGVsaXZlcnkgKD0gdHJpZ2dlciBtaXhlZCBtb2RlKSBhdCB0aGUgbW9tZW50IHRoZSBmaXJzdCBB
UElDIHdpdGgNCj4gZGlmZmVyZW50IERGUiBpcyBjb25maWd1cmVkLg0KDQpUaGFua3MgYSBsb3Qg
Zm9yIHlvdXIgZXhwbGFuYXRpb24hDQoNClRoYW5rcywNCkZlbmcNCg0KPiAtLQ0KPiBUbyB1bnN1
YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUga3ZtIiBp
bg0KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0K
PiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9t
by1pbmZvLmh0bWwNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web