* 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)
* Youquan Song youquan.s...@linux.intel.com 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.
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
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 relatively easy
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
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
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
> 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
>
* 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
* Youquan Song youquan.s...@linux.intel.com 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
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
patch from
On Sat, Aug 17, 2013 at 09:42:56AM +0200, Ingo Molnar wrote:
* Youquan Song youquan.s...@linux.intel.com 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.
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 youquan.s...@linux.intel.com wrote:
[]
Firstly, please use the customary (multi-line) comment
style:
/*
* Comment .
* .. goes
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
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 want
> 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
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 are
* 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
> 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
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 Ingo,
* Youquan Song youquan.s...@linux.intel.com 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
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,
On Thu, Jul 25, 2013 at 07:05:15AM -0700, Yinghai Lu wrote:
On Tue, Jul 23, 2013 at 11:22 PM, Gleb Natapov g...@redhat.com 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 youquan.s...@intel.com
wrote:
x2APIC extends APICID
> 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
> > 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
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 be
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
* 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.
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
On Tue, Jul 23, 2013 at 11:22 PM, Gleb Natapov g...@redhat.com 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 youquan.s...@intel.com wrote:
x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
routed
from
* Youquan Song youquan.s...@linux.intel.com wrote:
On Tue, Jul 23, 2013 at 11:17:29AM +0200, Ingo Molnar wrote:
* Youquan Song youquan.s...@intel.com wrote:
x2APIC extends APICID from 8 bits to 32 bits, but the device interrupt
routed from IOAPIC or delivered in MSI mode will
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
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
On Tue, Jul 23, 2013 at 09:24:45PM -0700, Yinghai Lu wrote:
On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song youquan.s...@intel.com 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.
On Tue, Jul 23, 2013 at 09:24:45PM -0700, Yinghai Lu wrote:
On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song youquan.s...@intel.com 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.
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
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
* 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
* Youquan Song youquan.s...@intel.com 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
On Tue, Jul 23, 2013 at 11:17:29AM +0200, Ingo Molnar wrote:
* Youquan Song youquan.s...@intel.com 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,
On Thu, Jul 11, 2013 at 6:22 PM, Youquan Song youquan.s...@intel.com 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
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
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
44 matches
Mail list logo
