* Youquan Song wrote:
> > Firstly, please use the customary (multi-line) comment
> > style:
> >
> > /*
> >* Comment .
> >* .. goes here.
> >*/
> >
> > specified in Documentation/CodingStyle.
> >
> > Secondly, please send a patch against a vanilla (e.g.
> > v3.11-rc5) k
On Sat, Aug 17, 2013 at 09:26:43AM -0700, Joe Perches wrote:
> > ... unless there's a way to detect new submissions and scream only
> > for those. I.e., look at lines starting with "+" which don't have
> > corresponding "-" lines.
>
> No, that's not the right way to do that.
> That bit's relativel
On Sat, 2013-08-17 at 17:44 +0200, Borislav Petkov wrote:
> On Sat, Aug 17, 2013 at 02:03:51AM -0700, Joe Perches wrote:
> > checkpatch tends to be used for firs patch submissions and
> > adding it would only encourage a new wave of trivial whitespace
> > patches.
>
> Nope, we definitely don't wan
On Sat, Aug 17, 2013 at 02:03:51AM -0700, Joe Perches wrote:
> checkpatch tends to be used for firs patch submissions and
> adding it would only encourage a new wave of trivial whitespace
> patches.
Nope, we definitely don't want that...
> I think there are already way, _way_ too many existing in
On Sat, 2013-08-17 at 10:24 +0200, Borislav Petkov wrote:
> On Sat, Aug 17, 2013 at 09:42:56AM +0200, Ingo Molnar wrote:
> >
> > * Youquan Song wrote:
[]
> > Firstly, please use the customary (multi-line) comment
> > style:
> >
> > /*
> >* Comment .
> >* .. goes here.
> >*
On Sat, Aug 17, 2013 at 09:42:56AM +0200, Ingo Molnar wrote:
>
> * Youquan Song wrote:
>
> > > No problem - you might want to send another patch adding some comments to
> > > the code, explaining why we don't switch to physical mode, quoting from
> > > the SDM and so.
> >
> > Here is the reve
> Firstly, please use the customary (multi-line) comment
> style:
>
> /*
>* Comment .
>* .. goes here.
>*/
>
> specified in Documentation/CodingStyle.
>
> Secondly, please send a patch against a vanilla (e.g.
> v3.11-rc5) kernel, as I've already zapped your previous
> pa
* Youquan Song wrote:
> > No problem - you might want to send another patch adding some comments to
> > the code, explaining why we don't switch to physical mode, quoting from
> > the SDM and so.
>
> Here is the revert patch.
>
> Subject: [PATCH] Revert "x86/apic: Enable x2APIC physical mode
> No problem - you might want to send another patch adding some comments to
> the code, explaining why we don't switch to physical mode, quoting from
> the SDM and so.
Here is the revert patch.
Subject: [PATCH] Revert "x86/apic: Enable x2APIC physical mode on native
hardware too, when there ar
* Youquan Song wrote:
> > In order to make sure the patch without involving unexpected issues beyond
> > I can understand, I will confirm with our expert about it.
> >
> > so please pend the patch going to mainline. If the patch can move on, I
> > think I will also provide other patch changing,
> In order to make sure the patch without involving unexpected issues beyond
> I can understand, I will confirm with our expert about it.
>
> so please pend the patch going to mainline. If the patch can move on, I
> think I will also provide other patch changing, like direct EOI.
Hi Yinghai and I
On Thu, Jul 25, 2013 at 07:05:15AM -0700, Yinghai Lu wrote:
> On Tue, Jul 23, 2013 at 11:22 PM, Gleb Natapov wrote:
> > On Tue, Jul 23, 2013 at 09:24:45PM -0700, Yinghai Lu wrote:
> >> On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song
> >> wrote:
> >> > x2APIC extends APICID from 8 bits to 32 bits,
> Yes. It would be great, if Youquan can point out where is the intel doc
> about the change.
>
> Also if the patch can move on, hypervisor_x2apic_available() related
> declaration and define
> could be dropped.
Hi Yinghai,
Sorry I do not know the document change but I also do not find the
word
> > Thanks Ingo!
> > The machines will be affected: CPU support x2APIC and CPU number < 256,
> > chipset does not support VT-d2 or VT-d is disabled in BIOS.
>
> I mean, can you guess what rough percentage of new systems
> shipping (or significant number of older systems already
> shipped) will
* Youquan Song wrote:
> On Tue, Jul 23, 2013 at 11:17:29AM +0200, Ingo Molnar wrote:
> >
> > * Youquan Song wrote:
> >
> > > x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
> > > routed from IOAPIC or delivered in MSI mode will keep 8 bits destination
> > > APICID. In
On Tue, Jul 23, 2013 at 11:22 PM, Gleb Natapov wrote:
> On Tue, Jul 23, 2013 at 09:24:45PM -0700, Yinghai Lu wrote:
>> On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song wrote:
>> > x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
>> > routed
>> > from IOAPIC or delivered in MSI
On Tue, Jul 23, 2013 at 09:24:45PM -0700, Yinghai Lu wrote:
> On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song wrote:
> > x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
> > routed
> > from IOAPIC or delivered in MSI mode will keep 8 bits destination APICID.
> > In order to su
On Tue, Jul 23, 2013 at 09:24:45PM -0700, Yinghai Lu wrote:
> On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song wrote:
> > x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
> > routed
> > from IOAPIC or delivered in MSI mode will keep 8 bits destination APICID.
> > In order to su
On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song wrote:
> x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt routed
> from IOAPIC or delivered in MSI mode will keep 8 bits destination APICID.
> In order to support x2APIC, the VT-d interrupt remapping is introduced to
> translate t
On Tue, Jul 23, 2013 at 11:17:29AM +0200, Ingo Molnar wrote:
>
> * Youquan Song wrote:
>
> > x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
> > routed from IOAPIC or delivered in MSI mode will keep 8 bits destination
> > APICID. In order to support x2APIC, the VT-d inte
* Youquan Song wrote:
> x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
> routed from IOAPIC or delivered in MSI mode will keep 8 bits destination
> APICID. In order to support x2APIC, the VT-d interrupt remapping is
> introduced to translate the destination APICID to 3
x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt routed
from IOAPIC or delivered in MSI mode will keep 8 bits destination APICID.
In order to support x2APIC, the VT-d interrupt remapping is introduced to
translate the destination APICID to 32 bits in x2APIC mode and keep the
22 matches
Mail list logo