On 13.11.14 at 11:25, jbeul...@suse.com wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
struct pdev_archdata {
};
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is
On 13.11.14 at 11:38, andrew.coop...@citrix.com wrote:
On 12/11/14 15:55, Jan Beulich wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+ u64 max_mfn;
+
+ max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL
>>> On 12.11.14 at 21:36, wrote:
> On Mon, Nov 10, 2014 at 11:42 PM, Jan Beulich wrote:
>>
>> Nothing crashes with the unwind information being wrong. It is
>> solely you who was claiming (without proof) years ago that the
>> unwinder repeatedly caused iss
>>> On 12.11.14 at 17:59, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>>
>>> On 12.11.14 at 16:25, wrote:
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> + u64 max_mfn;
> +
> + max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> +
> + return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
> +}
The value the hypercall
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+ u64 max_mfn;
+
+ max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+ return DMA_BIT_MASK(fls64(max_mfn PAGE_SHIFT) + 1);
+}
The value the
On 12.11.14 at 17:59, david.vra...@citrix.com wrote:
On 12/11/14 15:55, Jan Beulich wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+ u64 max_mfn;
+
+ max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL
On 12.11.14 at 21:36, torva...@linux-foundation.org wrote:
On Mon, Nov 10, 2014 at 11:42 PM, Jan Beulich jbeul...@suse.com wrote:
Nothing crashes with the unwind information being wrong. It is
solely you who was claiming (without proof) years ago that the
unwinder repeatedly caused issues
>>> On 10.11.14 at 19:10, wrote:
> Btw, the sane thing to do is to make your infrastructure just say "If
> my frame walker hits a push/pop without CFI information, I'll just add
> it myself".
>
> Yes, that involved having to actuall ylook at the instruction. Tough
> shit. Just do it right. There
>>> On 10.11.14 at 18:56, wrote:
> So no. A very strong NACK. The code was too ugly to live, there is no good
> stated reason for it, and the only reason I can even remotely imagine is
> wrong and complete crap anyway (ie making the CFI annotations a correctness
> issue by introducing other
On 10.11.14 at 18:56, torva...@linux-foundation.org wrote:
So no. A very strong NACK. The code was too ugly to live, there is no good
stated reason for it, and the only reason I can even remotely imagine is
wrong and complete crap anyway (ie making the CFI annotations a correctness
issue by
On 10.11.14 at 19:10, torva...@linux-foundation.org wrote:
Btw, the sane thing to do is to make your infrastructure just say If
my frame walker hits a push/pop without CFI information, I'll just add
it myself.
Yes, that involved having to actuall ylook at the instruction. Tough
shit. Just
allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).
Don't do this however for any VFs currently in active use by a guest.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c | 46
>>> On 05.11.14 at 18:23, wrote:
> On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich wrote:
>>>>> Andy Lutomirski 11/04/14 8:40 PM >>>
>>>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>>>> The main obstacle to having done this long ago was
allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).
Don't do this however for any VFs currently in active use by a guest.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
drivers/xen/xen-pciback
On 05.11.14 at 18:23, l...@amacapital.net wrote:
On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich jbeul...@suse.com wrote:
Andy Lutomirski l...@amacapital.net 11/04/14 8:40 PM
On 11/04/2014 01:24 AM, Jan Beulich wrote:
The main obstacle to having done this long ago was the need to
determine
>>> Andy Lutomirski 11/04/14 8:40 PM >>>
>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>> The main obstacle to having done this long ago was the need to
>> determine whether annotations are needed in the first place: They need
>> to be avoided when a fram
>>> Andy Lutomirski 11/04/14 8:33 PM >>>
>On 11/04/2014 12:49 AM, Jan Beulich wrote:
>> Observing that per-CPU data (in the SMP case) is reachable by
>> exploiting 64-bit address wraparound, these two patches
>> arrange for using the one byte s
>>> "H. Peter Anvin" 11/04/14 9:11 PM >>>
>On 11/04/2014 11:45 AM, tip-bot for Jan Beulich wrote:
>> x86-64: Use RIP-relative addressing for most per-CPU accesses
>>
>> Observing that per-CPU data (in the SMP case) is reachable by
>> exploi
H. Peter Anvin h...@zytor.com 11/04/14 9:11 PM
On 11/04/2014 11:45 AM, tip-bot for Jan Beulich wrote:
x86-64: Use RIP-relative addressing for most per-CPU accesses
Observing that per-CPU data (in the SMP case) is reachable by
exploiting 64-bit address wraparound (building on the default
Andy Lutomirski l...@amacapital.net 11/04/14 8:33 PM
On 11/04/2014 12:49 AM, Jan Beulich wrote:
Observing that per-CPU data (in the SMP case) is reachable by
exploiting 64-bit address wraparound, these two patches
arrange for using the one byte shorter RIP-relative addressing
forms
Andy Lutomirski l...@amacapital.net 11/04/14 8:40 PM
On 11/04/2014 01:24 AM, Jan Beulich wrote:
The main obstacle to having done this long ago was the need to
determine whether annotations are needed in the first place: They need
to be avoided when a frame pointer got set up. Since I can't
Commit-ID: 97b67ae559947f1e208439a1bf6a734da3087006
Gitweb: http://git.kernel.org/tip/97b67ae559947f1e208439a1bf6a734da3087006
Author: Jan Beulich
AuthorDate: Tue, 4 Nov 2014 08:50:48 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:43:14 +0100
x86-64: Use RIP-relative
Commit-ID: 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba
Gitweb: http://git.kernel.org/tip/6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba
Author: Jan Beulich
AuthorDate: Tue, 4 Nov 2014 08:50:18 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:43:14 +0100
x86-64: Handle PC
Commit-ID: 2c773dd31fbacbbb6425f8a9d3f97e0010272368
Gitweb: http://git.kernel.org/tip/2c773dd31fbacbbb6425f8a9d3f97e0010272368
Author: Jan Beulich
AuthorDate: Tue, 4 Nov 2014 08:26:42 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:13:28 +0100
x86: Convert a few more
Commit-ID: 8c66877ee65ec4e6974e9aa69bc53abe4a603f10
Gitweb: http://git.kernel.org/tip/8c66877ee65ec4e6974e9aa69bc53abe4a603f10
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:39:43 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:11:59 +0100
x86: Avoid building
Commit-ID: 3b67bdc6599e25b082f12dbde6b0ce91dd235549
Gitweb: http://git.kernel.org/tip/3b67bdc6599e25b082f12dbde6b0ce91dd235549
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:15:42 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 19:12:41 +0100
x86: irq: Fix placement
/kprobes/
arch/x86/kernel/kvm/
drivers/char/i8k.c:i8k_smm()
drivers/char/toshiba.c:tosh_smm()
drivers/lguest/x86/
Signed-off-by: Jan Beulich
Cc: Tony Jones
---
arch/x86/Makefile| 22
arch/x86/include/asm/frame.h | 103
pendency on the minimum kernel load address, arbitrarily
low values for CONFIG_PHYSICAL_START are now no longer possible. A
link time assertion is being added, directing to the need to increase
that value when it triggers.
Signed-off-by: Jan Beulich
---
arch/x
addressing for most per-CPU accesses
Signed-off-by: Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
This is in preparation of using RIP-relative addressing in many of the
per-CPU accesses.
Signed-off-by: Jan Beulich
---
arch/x86/boot/compressed/misc.c | 14 +-
arch/x86/tools/relocs.c | 38 --
2 files changed, 41 insertions(+), 11
converted to per-CPU data years ago).
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/percpu.h|2 +-
arch/x86/include/asm/processor.h |4 ++--
arch/x86/kernel/setup_percpu.c |2 +-
arch/x86/kernel/smpboot.c|2 +-
4 files changed, 5 insertions(+), 5 deletions
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch
I'm about to post as RFC.
Signed-off-by: Jan Beulich
---
include/linux/irqflags.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 3.18-rc3
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch
I'm about to post as RFC.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
include/linux/irqflags.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions
converted to per-CPU data years ago).
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/include/asm/percpu.h|2 +-
arch/x86/include/asm/processor.h |4 ++--
arch/x86/kernel/setup_percpu.c |2 +-
arch/x86/kernel/smpboot.c|2 +-
4 files changed, 5 insertions
This is in preparation of using RIP-relative addressing in many of the
per-CPU accesses.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/boot/compressed/misc.c | 14 +-
arch/x86/tools/relocs.c | 38 --
2 files changed, 41
addressing for most per-CPU accesses
Signed-off-by: Jan Beulich jbeul...@suse.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
address, arbitrarily
low values for CONFIG_PHYSICAL_START are now no longer possible. A
link time assertion is being added, directing to the need to increase
that value when it triggers.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/include/asm/percpu.h | 59
/kprobes/
arch/x86/kernel/kvm/
drivers/char/i8k.c:i8k_smm()
drivers/char/toshiba.c:tosh_smm()
drivers/lguest/x86/
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Tony Jones to...@suse.de
---
arch/x86/Makefile| 22
arch/x86/include/asm/frame.h | 103
Commit-ID: 3b67bdc6599e25b082f12dbde6b0ce91dd235549
Gitweb: http://git.kernel.org/tip/3b67bdc6599e25b082f12dbde6b0ce91dd235549
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 3 Nov 2014 08:15:42 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 4 Nov 2014 19:12
Commit-ID: 8c66877ee65ec4e6974e9aa69bc53abe4a603f10
Gitweb: http://git.kernel.org/tip/8c66877ee65ec4e6974e9aa69bc53abe4a603f10
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Mon, 3 Nov 2014 08:39:43 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 4 Nov 2014 20:11
Commit-ID: 2c773dd31fbacbbb6425f8a9d3f97e0010272368
Gitweb: http://git.kernel.org/tip/2c773dd31fbacbbb6425f8a9d3f97e0010272368
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 4 Nov 2014 08:26:42 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 4 Nov 2014 20:13
Commit-ID: 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba
Gitweb: http://git.kernel.org/tip/6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 4 Nov 2014 08:50:18 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 4 Nov 2014 20:43
Commit-ID: 97b67ae559947f1e208439a1bf6a734da3087006
Gitweb: http://git.kernel.org/tip/97b67ae559947f1e208439a1bf6a734da3087006
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 4 Nov 2014 08:50:48 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 4 Nov 2014 20:43
>>> On 03.11.14 at 23:18, wrote:
> On Mon, Nov 03, 2014 at 04:41:13PM +, Jan Beulich wrote:
>> having run into that warning too, I looked into it a little, and now
>> having found that patch am pretty uncertain: Both truncate_setsize()
>> and pagecache_isize_exte
Jan,
having run into that warning too, I looked into it a little, and now
having found that patch am pretty uncertain: Both truncate_setsize()
and pagecache_isize_extended() document that they want to be
called with i_mutex held, so removing the WARN_ON() alone seems
either incomplete or wrong.
padding
bytes each of the final four sets have) this doesn't seem to provide
any real benefit: Both irq_entries_start and common_interrupt getting
cache line aligned, eliminating the 30th set would just produce 32
bytes of padding between the 29th and common_interrupt.
Signed-off-by: Jan Beulich
t out when !CONFIG_X86_IO_APIC was at least
questionable.
Signed-off-by: Jan Beulich
Cc: Jiang Liu
---
Note: This replaces (rather than fixes) the previously sent "ix86: fix
build failure when !CONFIG_X86_IO_APIC" (which conflicts with the
commit mentioned above).
---
arch/x86/include/
!CONFIG_X86_IO_APIC was at least
questionable.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Jiang Liu jiang@linux.intel.com
---
Note: This replaces (rather than fixes) the previously sent ix86: fix
build failure when !CONFIG_X86_IO_APIC (which conflicts with the
commit mentioned above).
---
arch
padding
bytes each of the final four sets have) this doesn't seem to provide
any real benefit: Both irq_entries_start and common_interrupt getting
cache line aligned, eliminating the 30th set would just produce 32
bytes of padding between the 29th and common_interrupt.
Signed-off-by: Jan Beulich jbeul
Jan,
having run into that warning too, I looked into it a little, and now
having found that patch am pretty uncertain: Both truncate_setsize()
and pagecache_isize_extended() document that they want to be
called with i_mutex held, so removing the WARN_ON() alone seems
either incomplete or wrong.
On 03.11.14 at 23:18, da...@fromorbit.com wrote:
On Mon, Nov 03, 2014 at 04:41:13PM +, Jan Beulich wrote:
having run into that warning too, I looked into it a little, and now
having found that patch am pretty uncertain: Both truncate_setsize()
and pagecache_isize_extended() document
>>> On 29.10.14 at 08:50, wrote:
> * Jan Beulich wrote:
>
>> >>> On 28.10.14 at 12:18, wrote:
>> > Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
>> > Gitweb:
> http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
On 29.10.14 at 08:50, mi...@kernel.org wrote:
* Jan Beulich jbeul...@suse.com wrote:
On 28.10.14 at 12:18, tip...@zytor.com wrote:
Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
Gitweb:
http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
Author: Jan
>>> On 28.10.14 at 12:18, wrote:
> Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
> Gitweb:
> http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
> Author: Jan Beulich
> AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
> Committer: Ingo Mo
Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
Gitweb: http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
Author: Jan Beulich
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 12:01:09 +0100
ix86: Fix build failure
Commit-ID: de8bf1a32bd379a4f953c3146b82c8a438d7aa5d
Gitweb: http://git.kernel.org/tip/de8bf1a32bd379a4f953c3146b82c8a438d7aa5d
Author: Jan Beulich
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar
CommitDate: Tue, 28 Oct 2014 11:06:16 +0100
ix86: Fix build failure
Commit-ID: de8bf1a32bd379a4f953c3146b82c8a438d7aa5d
Gitweb: http://git.kernel.org/tip/de8bf1a32bd379a4f953c3146b82c8a438d7aa5d
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 28 Oct 2014 11:06:16
Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
Gitweb: http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 28 Oct 2014 12:01:09
On 28.10.14 at 12:18, tip...@zytor.com wrote:
Commit-ID: a425cf83e39f99a70168c184e79cea8c67ba7c12
Gitweb:
http://git.kernel.org/tip/a425cf83e39f99a70168c184e79cea8c67ba7c12
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Tue, 16 Sep 2014 13:44:24 +0100
Committer: Ingo Molnar
Commit-ID: f74954f01ec9bb2004bcc24f247d1f26f1063ad2
Gitweb: http://git.kernel.org/tip/f74954f01ec9bb2004bcc24f247d1f26f1063ad2
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:41:30 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 12:31:45 +0200
x86: Unwind-annotate
Commit-ID: 3f63572187f5ae6a0a9e5ebee88b57e6f71c3cd4
Gitweb: http://git.kernel.org/tip/3f63572187f5ae6a0a9e5ebee88b57e6f71c3cd4
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:37:00 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 10:05:49 +0200
x86: Improve
Commit-ID: 82ef36449d311a29b20f82fdce0de856057fa691
Gitweb: http://git.kernel.org/tip/82ef36449d311a29b20f82fdce0de856057fa691
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:41:30 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 10:05:50 +0200
x86: Unwind-annotate
Commit-ID: 5f1d919a8ca15f450c749227bc5e2e18f3cbfdb4
Gitweb: http://git.kernel.org/tip/5f1d919a8ca15f450c749227bc5e2e18f3cbfdb4
Author: Jan Beulich
AuthorDate: Wed, 24 Sep 2014 08:40:14 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 8 Oct 2014 10:05:49 +0200
x86: Improve
Commit-ID: 5f1d919a8ca15f450c749227bc5e2e18f3cbfdb4
Gitweb: http://git.kernel.org/tip/5f1d919a8ca15f450c749227bc5e2e18f3cbfdb4
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Wed, 24 Sep 2014 08:40:14 +0100
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 8 Oct 2014 10:05
Commit-ID: 82ef36449d311a29b20f82fdce0de856057fa691
Gitweb: http://git.kernel.org/tip/82ef36449d311a29b20f82fdce0de856057fa691
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Wed, 24 Sep 2014 08:41:30 +0100
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 8 Oct 2014 10:05
Commit-ID: 3f63572187f5ae6a0a9e5ebee88b57e6f71c3cd4
Gitweb: http://git.kernel.org/tip/3f63572187f5ae6a0a9e5ebee88b57e6f71c3cd4
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Wed, 24 Sep 2014 08:37:00 +0100
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 8 Oct 2014 10:05
Commit-ID: f74954f01ec9bb2004bcc24f247d1f26f1063ad2
Gitweb: http://git.kernel.org/tip/f74954f01ec9bb2004bcc24f247d1f26f1063ad2
Author: Jan Beulich jbeul...@suse.com
AuthorDate: Wed, 24 Sep 2014 08:41:30 +0100
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 8 Oct 2014 12:31
>>> On 29.09.14 at 06:32, wrote:
> On 09/26/2014 06:38 PM, Chen Gang wrote:
>> When failure occurs, after xenbus_dev_error(), need go to fail to let
>> upper caller know about it.
>>
>> Signed-off-by: Chen Gang
>> ---
>> drivers/xen/xen-scsiback.c | 4 +++-
>> 1 file changed, 3 insertions(+),
On 29.09.14 at 06:32, jgr...@suse.com wrote:
On 09/26/2014 06:38 PM, Chen Gang wrote:
When failure occurs, after xenbus_dev_error(), need go to fail to let
upper caller know about it.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
drivers/xen/xen-scsiback.c | 4 +++-
1 file
Signed-off-by: Jan Beulich
---
arch/x86/lib/thunk_32.S | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- 3.17-rc6/arch/x86/lib/thunk_32.S
+++ 3.17-rc6-ix86-annotate-thunks/arch/x86/lib/thunk_32.S
@@ -6,22 +6,31 @@
*/
#include
#include
- don't include unneeded headers
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local labels to not clutter the symbol table
Signed-off-by: Jan Beulich
---
arch/x86/lib/cmpxchg8b_emu.S | 20 +---
1 file changed, 9 insertions(+), 11
- don't include unneeded headers
- don't open-code PER_CPU_VAR()
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local label to not clutter the symbol table
Signed-off-by: Jan Beulich
---
arch/x86/lib/cmpxchg16b_emu.S | 32
- don't include unneeded headers
- don't open-code PER_CPU_VAR()
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local label to not clutter the symbol table
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/lib/cmpxchg16b_emu.S | 32
- don't include unneeded headers
- drop redundant entry point label
- complete unwind annotations
- use .L prefix on local labels to not clutter the symbol table
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/lib/cmpxchg8b_emu.S | 20 +---
1 file changed, 9
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/lib/thunk_32.S | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
--- 3.17-rc6/arch/x86/lib/thunk_32.S
+++ 3.17-rc6-ix86-annotate-thunks/arch/x86/lib/thunk_32.S
@@ -6,22 +6,31 @@
*/
#include linux
>>> On 17.09.14 at 16:07, wrote:
> On 17/09/14 05:12, Juergen Gross wrote:
>> +static void __init xen_cleanmfnmap(unsigned long vaddr)
>> +{
>> +unsigned long va = vaddr & PMD_MASK;
>> +unsigned long pa;
>> +pgd_t *pgd = pgd_offset_k(va);
>> +pud_t *pud_page = pud_offset(pgd, 0);
On 17.09.14 at 16:07, david.vra...@citrix.com wrote:
On 17/09/14 05:12, Juergen Gross wrote:
+static void __init xen_cleanmfnmap(unsigned long vaddr)
+{
+unsigned long va = vaddr PMD_MASK;
+unsigned long pa;
+pgd_t *pgd = pgd_offset_k(va);
+pud_t *pud_page =
:1259: error: implicit declaration of function
‘mp_should_keep_irq’
make[3]: *** [arch/x86/pci/irq.o] Error 1
Move them to better places.
Signed-off-by: Jan Beulich
Cc: Jiang Liu
---
arch/x86/include/asm/io_apic.h |2 --
arch/x86/include/asm/pci_x86.h |2 ++
arch/x86/kernel/apic
Andy
following e6577a7ce9 ("x86, vdso: Move the vvar area before the
vdso text") gcc 4.3.4 tells me
.../arch/x86/vdso/vdso2c.c: In function ‘main’:
.../arch/x86/vdso/vdso2c.h:118: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is
always false
Andy
following e6577a7ce9 (x86, vdso: Move the vvar area before the
vdso text) gcc 4.3.4 tells me
.../arch/x86/vdso/vdso2c.c: In function ‘main’:
.../arch/x86/vdso/vdso2c.h:118: warning: assuming signed overflow does not
occur when assuming that (X + c) X is
always false
:1259: error: implicit declaration of function
‘mp_should_keep_irq’
make[3]: *** [arch/x86/pci/irq.o] Error 1
Move them to better places.
Signed-off-by: Jan Beulich jbeul...@suse.com
Cc: Jiang Liu jiang@linux.intel.com
---
arch/x86/include/asm/io_apic.h |2 --
arch/x86/include/asm
>>> On 04.09.14 at 15:02, wrote:
> On 04/09/14 13:59, David Vrabel wrote:
>> On 04/09/14 13:38, Juergen Gross wrote:
>>> Direct Xen to place the initial P->M table outside of the initial
>>> mapping, as otherwise the 1G (implementation) / 2G (theoretical)
>>> restriction on the size of the
>>> On 04.09.14 at 14:52, wrote:
> On 04/09/14 13:38, Juergen Gross wrote:
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -124,6 +124,9 @@ NEXT_HYPERCALL(arch_6)
>> ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
>> .quad _PAGE_PRESENT; .quad _PAGE_PRESENT)
>>
>>> On 04.09.14 at 14:38, <"jgr...@suse.com".non-mime.internet> wrote:
> As the KEXEC and DUMPCORE related ELFNOTES are not relevant for the
> kernel they are omitted from elfnote.h.
But the defines are still in the patch:
> @@ -153,6 +192,65 @@
> */
> #define XEN_ELFNOTE_SUPPORTED_FEATURES
On 04.09.14 at 14:38, jgr...@suse.com.non-mime.internet wrote:
As the KEXEC and DUMPCORE related ELFNOTES are not relevant for the
kernel they are omitted from elfnote.h.
But the defines are still in the patch:
@@ -153,6 +192,65 @@
*/
#define XEN_ELFNOTE_SUPPORTED_FEATURES 17
+/*
+
On 04.09.14 at 14:52, david.vra...@citrix.com wrote:
On 04/09/14 13:38, Juergen Gross wrote:
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -124,6 +124,9 @@ NEXT_HYPERCALL(arch_6)
ELFNOTE(Xen, XEN_ELFNOTE_L1_MFN_VALID,
.quad _PAGE_PRESENT; .quad
On 04.09.14 at 15:02, andrew.coop...@citrix.com wrote:
On 04/09/14 13:59, David Vrabel wrote:
On 04/09/14 13:38, Juergen Gross wrote:
Direct Xen to place the initial P-M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
restriction on the size of
>>> On 29.08.14 at 16:27, wrote:
> Sure. Btw, someone also contacted me saying they have the same problem
> without
> changing the layout but having really big initrd (500M). While that feels
> like
> it should be impossible (if the kernel+initrd+xen stuff has to fix the 512M
> kernel image
On 29.08.14 at 16:27, stefan.ba...@canonical.com wrote:
Sure. Btw, someone also contacted me saying they have the same problem
without
changing the layout but having really big initrd (500M). While that feels
like
it should be impossible (if the kernel+initrd+xen stuff has to fix the 512M
>>> On 28.08.14 at 16:08, wrote:
> The Xen change that broke Linux PVH guests must be reverted. This
> change may also have broken other guests (e.g., Mirage or one of the
> other unikernel OSes).
If PVH wasn't tech preview, I'd agree. But since it is, I don't see a
reason to revert that
On 28.08.14 at 16:08, david.vra...@citrix.com wrote:
The Xen change that broke Linux PVH guests must be reverted. This
change may also have broken other guests (e.g., Mirage or one of the
other unikernel OSes).
If PVH wasn't tech preview, I'd agree. But since it is, I don't see a
reason to
>>> On 27.08.14 at 09:30, wrote:
> I'm curious about the difference. :-)
>
> sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit()
> is used in all other places. What makes hv/xen special?
I guess this would really want to be used by anything communicating
with a
On 27.08.14 at 09:30, de...@microsoft.com wrote:
I'm curious about the difference. :-)
sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit()
is used in all other places. What makes hv/xen special?
I guess this would really want to be used by anything communicating
>>> On 19.08.14 at 15:25, wrote:
> @@ -118,8 +167,14 @@ void pat_init(void)
> PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
>
> /* Boot CPU check */
> - if (!boot_pat_state)
> + if (!boot_pat_state) {
> rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
>>> On 21.08.14 at 11:30, wrote:
> On 08/20/2014 09:26 PM, Toshi Kani wrote:
>> On Tue, 2014-08-19 at 15:25 +0200, jgr...@suse.com wrote:
>>> --- a/arch/x86/mm/init.c
>>> +++ b/arch/x86/mm/init.c
>>> @@ -27,6 +27,35 @@
>>>
>>> #include "mm_internal.h"
>>>
>>> +/*
>>> + * Tables translating
On 21.08.14 at 11:30, jgr...@suse.com wrote:
On 08/20/2014 09:26 PM, Toshi Kani wrote:
On Tue, 2014-08-19 at 15:25 +0200, jgr...@suse.com wrote:
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -27,6 +27,35 @@
#include mm_internal.h
+/*
+ * Tables translating between
On 19.08.14 at 15:25, jgr...@suse.com wrote:
@@ -118,8 +167,14 @@ void pat_init(void)
PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
/* Boot CPU check */
- if (!boot_pat_state)
+ if (!boot_pat_state) {
rdmsrl(MSR_IA32_CR_PAT,
>>> One Thousand Gnomes 08/20/14 2:08 PM >>>
>> The Linux kernel currently supports only 4 different cache modes. The PAT MSR
>> is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
>> top 4 entries in the PAT MSR are the same as the 4 lower entries.
>>
>> This results
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk 08/20/14 2:08 PM
The Linux kernel currently supports only 4 different cache modes. The PAT MSR
is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the
top 4 entries in the PAT MSR are the same as the 4 lower entries.
This
901 - 1000 of 2685 matches
Mail list logo
