>>> On 17.06.13 at 11:21, Matt Fleming wrote:
> On Fri, 14 Jun, at 12:00:33AM, joeyli wrote:
>> > From: Zach Bobroff
>> > --- a/arch/x86/boot/compressed/eboot.c
>> > +++ b/arch/x86/boot/compressed/eboot.c
>> > @@ -1037,18 +1037,20 @@ static efi_status_t exit_boot(struct boot_params
>> > *boot_pa
>>> On 17.06.13 at 12:17, Matt Fleming wrote:
> On Mon, 17 Jun, at 10:46:28AM, Jan Beulich wrote:
>> I agree that there ought to be an upper limit. But a single retry here
>> again looks like a tailored solution to a particular observed (mis-)
>> behavior, rather
>>> On 04.06.13 at 10:05, liguang wrote:
> bm_rld_set seems obsolete now
>
> Signed-off-by: liguang
> ---
> include/xen/interface/platform.h |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/include/xen/interface/platform.h
> b/include/xen/interface/platform.h
> in
>>> On 04.06.13 at 02:43, Mukesh Rathor wrote:
> @@ -1327,6 +1329,18 @@ static void __init xen_setup_stackprotector(void)
> /* PVH TBD/FIXME: investigate setup_stack_canary_segment */
> if (xen_feature(XENFEAT_auto_translated_physmap)) {
> switch_to_new_gdt(0);
> +
> +
>>> On 04.06.13 at 23:53, Mukesh Rathor wrote:
> Following OK? :
>
> if (xen_feature(XENFEAT_auto_translated_physmap)) {
> switch_to_new_gdt(0);
>
> asm volatile (
> "pushq %%rax\n"
> "leaq 1f(%%rip),%%rax\n"
hat is false, so we continue on looping (this bug).
>
> If we re-use said macro RING_REQUEST_CONS_OVERFLOW and pass in the rp
> instead (sring->req_prod) of rc, the this macro can do the check:
>
> req_prod - sring->rsp_prov_pvt >= 32
>
> Which is,
>
>>> On 05.06.13 at 19:35, Konrad Rzeszutek Wilk wrote:
>> > Looking at the code, one would expect that the existing check
>>
>> The "expect ..." here doesn't really seem to have a proper
>> termination later in the sentence (or I'm having problems parsing
>> the whole construct), so if I didn't k
>>> On 05.06.13 at 21:17, Mukesh Rathor wrote:
> On Wed, 05 Jun 2013 08:03:12 +0100
> "Jan Beulich" wrote:
>
>> >>> On 04.06.13 at 23:53, Mukesh Rathor
>> >>> wrote:
>> > Following OK? :
>>> On 05.06.13 at 17:54, Konrad Rzeszutek Wilk wrote:
> This patch adds a new structure to contain the common two things
> that each of the per-cpu interrupts need:
> - an interrupt number,
> - and the name of the interrupt (to be added in 'xen/smp: Don't leak
>interrupt name when offlining
>>> On 05.06.13 at 19:35, Konrad Rzeszutek Wilk wrote:
> @@ -230,6 +231,7 @@ static int xen_blkif_map(struct xen_blkif *blkif,
> unsigned long shared_page,
> static void xen_blkif_disconnect(struct xen_blkif *blkif)
> {
> if (blkif->xenblkd) {
> + wake_up(&blkif->shutdown_wq);
>>> Zachary Bobroff 06/18/13 2:25 AM >>>
> We only need to retry once because of what is in the UEFI specification 2.3.1
> Errata
> C. The exact verbiage is as follows:
>
> The ExitBootServices() function is called by the currently executing EFI OS
> loader
> image to terminate all boot service
>>> On 19.06.13 at 17:25, David Vrabel wrote:
> syscore_suspend() and syscore_resume() expect there to be only one
> online CPU. e.g., hrtimers_resume() only triggers events for the
> current CPU. Xen's suspend path was leaving all VCPUs online and then
> attempting to fixup problems afterwards
>>> On 19.06.13 at 17:25, David Vrabel wrote:
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -211,6 +211,26 @@ static int xen_set_wallclock(const struct timespec *now)
>
> return HYPERVISOR_dom0_op(&op);
> }
> +
> +static int xen_clock_was_set_notify(struct notifier_block *
The vsyscall related pvclock entries can only ever be used on x86-64,
and hence they shouldn't even get allocated for 32-bit kernels (the
more that it is there where address space is relatively precious).
Signed-off-by: Jan Beulich
Cc: Marcelo Tosatti
---
arch/x86/include/asm/fixmap.h |
: Jan Beulich
---
arch/x86/include/asm/special_insns.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.10-rc3/arch/x86/include/asm/special_insns.h
+++ 3.10-rc3-x86-force-order/arch/x86/include/asm/special_insns.h
@@ -16,7 +16,7 @@ static inline void native_clts(void)
* all loads
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 3.10-rc3/drivers/xen/xen-pciback/pci_stub.c
+++ 3.10-rc3-xen-pciback-MSI-X-cap/drivers/xen/xen-pciback/pci_stub.c
@@ -106,7 +106,7 @@ static void
binutils prior to 2.18 (e.g. the ones found on SLE10) don't support
assembling PEXTRD, so a macro based approach like the one for PCLMULQDQ
in the same file should be used.
This requires making the helper macros capable of recognizing 32-bit
general purpose register operands.
Signed-off-by
>>> On 31.05.13 at 01:55, John Stultz wrote:
> The first is probably the easiest, but I do want to make sure that Xen
> maintainers agree that Xen really needs to be special here compared to
> every other platform and always enforce the RTC is synced with system time.
Actually, during the v2 di
off-by: Wei Yongjun
Acked-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 FAQ at http://www.tux.org/lkml/
>>> On 21.06.13 at 12:56, Roger Pau Monne wrote:
> @@ -1236,7 +1236,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>seg[i].nsec << 9,
>seg[i].offset) == 0)) {
>
> - bio = bio_alloc(GFP_KERN
>>> On 21.06.13 at 12:56, Roger Pau Monne wrote:
> When using certain storage devices (like RAID) having a bigger number
> of segments per request provides better performance.
And there's no drawback (higher memory foot print if nothing else)
on "certain other storage devices"? Adjusting defaults
>>> On 07.06.13 at 22:11, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 04, 2013 at 03:57:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> +/* N.B. 'rp', not 'rc'. */
>> +if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rp)) {
>> +pr_warn(DRV_PFX "Frontend provided bogus ring request
>>> On 10.06.13 at 23:06, Konrad Rzeszutek Wilk wrote:
> There are two tool-stack that can instruct the Xen PCI frontend
> and backend to change states: 'xm' (Python code with a daemon),
> and 'xl' (C library - does not keep state changes).
>
> With the 'xm', the path to disconnect a PCI device (
>>> On 10.06.13 at 18:43, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 10, 2013 at 04:52:35PM +0100, Jan Beulich wrote:
>> >>> On 07.06.13 at 22:11, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Tue, Jun 04, 2013 at 03:57:06PM -0400, Konrad
this, requiring a parameter to be added to the
> hook function to distinguish "extended" from "legacy" sleep.
>
> Signed-off-by: Ben Guthro
> Signed-off-by: Jan Beulich
I think these are intended to reflect the flow of things, so
should be reversed (also in the
>>> On 26.06.13 at 16:06, Ben Guthro wrote:
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -273,7 +273,8 @@ static void tboot_copy_fadt(const struct acpi_table_fadt
> *fadt)
> offsetof(struct acpi_table_facs, firmware_waking_vector);
> }
>
> -static int tboo
>>> On 26.06.13 at 16:55, Ben Guthro wrote:
> On Wed, Jun 26, 2013 at 10:44 AM, Jan Beulich wrote:
>>>>> On 26.06.13 at 16:06, Ben Guthro wrote:
>>> --- a/arch/x86/kernel/tboot.c
>>> +++ b/arch/x86/kernel/tboot.c
>>> @@ -27
>>> On 26.06.13 at 17:03, Ben Guthro wrote:
> On Wed, Jun 26, 2013 at 10:41 AM, Jan Beulich wrote:
>>>>> On 26.06.13 at 16:06, Ben Guthro wrote:
>>> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
>>> reduced hardware
>>> On 27.06.13 at 17:02, Ben Guthro wrote:
> Change the function definitions of acpi_os_prepare_sleep() and
> acpi_os_set_prepare_sleep() to pass along the new extended sleep
> parameter.
>
> Signed-off-by: Jan Beulich
> Signed-off-by: Ben Guthro
> Cc: Bob M
>>> On 22.03.13 at 12:58, Zhu Yanhai wrote:
> Hi all,
> In the documention it reads,
>
> (2) UNLOCK operation implication:
>
> Memory operations issued before the UNLOCK will be completed before the
> UNLOCK operation has completed.
>
> Memory operations issued after the UNLOCK m
>>> On 21.08.13 at 16:12, Cyrill Gorcunov wrote:
> On Wed, Aug 21, 2013 at 02:48:20PM +0100, David Vrabel wrote:
>> All,
>>
>> 179ef71c (mm: save soft-dirty bits on swapped pages) introduces a new
>> PTE bit on x86 _PTE_SWP_SOFT_DIRTY which has the same value as _PTE_PSE
>> and _PTE_PAT.
>>
>> W
>>> On 21.08.13 at 17:42, Cyrill Gorcunov wrote:
> On Wed, Aug 21, 2013 at 03:53:36PM +0100, Jan Beulich wrote:
>> >>> On 21.08.13 at 16:12, Cyrill Gorcunov wrote:
>> > David, could you please explain, Xen keeps and analyze _PTE_PAT bit
>> > for ptes
>>> On 21.08.13 at 18:19, Cyrill Gorcunov wrote:
> On Wed, Aug 21, 2013 at 05:03:13PM +0100, Jan Beulich wrote:
>> >
>> > Only to non-present ptes, as far as I know.
>>
>> That's not really any guarantee. And the accessor functions also
>>
>>> On 22.08.13 at 09:03, Cyrill Gorcunov wrote:
> Ok, how about this?
>
> static inline pte_t pte_swp_mksoft_dirty(pte_t pte)
> {
> BUG_ON(pte_present(pte));
> return pte_set_flags(pte, _PAGE_SWP_SOFT_DIRTY);
> }
Sure, fine with me. Perhaps VM_BUG_ON() or some other similar
construc
>>> On 22.08.13 at 01:04, Linus Torvalds wrote:
> On Wed, Aug 21, 2013 at 12:03 PM, Cyrill Gorcunov wrote:
>>
>> I personally don't see bug here because
>>
>> - this swapped page soft dirty bit is set for non-present entries only,
>>never for present ones, just at moment we form swap pte ent
>>> On 21.08.13 at 19:28, Andy Lutomirski wrote:
> On Wed, Aug 21, 2013 at 6:48 AM, David Vrabel wrote:
>> All,
>>
>> 179ef71c (mm: save soft-dirty bits on swapped pages) introduces a new
>> PTE bit on x86 _PTE_SWP_SOFT_DIRTY which has the same value as _PTE_PSE
>> and _PTE_PAT.
>>
>> With a Xen
>>> On 22.08.13 at 13:27, Cyrill Gorcunov wrote:
> On Thu, Aug 22, 2013 at 08:27:45AM +0100, Jan Beulich wrote:
>> >>> On 22.08.13 at 09:03, Cyrill Gorcunov wrote:
>> > Ok, how about this?
>> >
>> > static inline pte_t pte_swp_mksoft_
>>> On 03.03.13 at 11:20, Paul Bolle wrote:
> Perhaps Konrad, Jan, Or Ian can tell whether the patch still needs to go
> in stable as is, because the problem it fixes is more severe than the
> problem it apparently creates. Maybe a mainline fix is needed before
> this can go in, or perhaps even a
>>> On 04.03.13 at 10:11, Paul Bolle wrote:
> On Mon, 2013-03-04 at 07:55 +, Jan Beulich wrote:
>> >>> On 03.03.13 at 11:20, Paul Bolle wrote:
>> For one, a fix for the (indeed valid) compiler warning has been in
>> Konrad's tree for several
>>> On 04.03.13 at 18:19, Roger Pau Monné wrote:
> On 28/02/13 11:58, Jan Beulich wrote:
>>>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
>> And then the biolist[] array really can be folded into a union
>> with the remaining seg[] one, as their usage sco
>>> On 04.03.13 at 21:44, Konrad Rzeszutek Wilk wrote:
> 'op' sounds good. With a comment saying it can do all of the
> BLKIF_OPS_..
> except the BLKIF_OP_INDIRECT one. Thought one could in theory chain
> it that way for fun.
In fact I'd like to exclude chaining as well as BLKIF_OP_DISCARD here
>>> On 14.05.13 at 02:52, John Stultz wrote:
> Honestly, it seems a little strange to me. If you're running as dom0,
> why does HYPERVISOR_dom0_op() not cause the hypervisor to set the cmos
> its virtualizing? This seems to mess with the proper virtualization
> layering.
Thy hypervisor tries t
>>> On 14.05.13 at 17:59, John Stultz wrote:
> On 05/14/2013 12:57 AM, Jan Beulich wrote:
>>>>> On 14.05.13 at 02:52, John Stultz wrote:
>>> Honestly, it seems a little strange to me. If you're running as dom0,
>>> why does HYPERVISOR_dom0_op(
>>> On 14.05.13 at 19:15, John Stultz wrote:
> On 05/14/2013 02:47 AM, David Vrabel wrote:
>> On 14/05/13 01:40, John Stultz wrote:
>>> I'm sorry, this isn't quite making sense to me. Could you further
>>> describe the exact problematic behavior you're seeing here, and why its
>>> a problem?
>> Th
>>> On 14.05.13 at 19:24, John Stultz wrote:
> On 05/13/2013 10:56 AM, David Vrabel wrote:
>> From: David Vrabel
>>
>> If NTP is used in dom0 and it is synchronized to its clock source,
>> then the kernel will periodically synchronize the Xen wallclock with
>> the system time. Updates to the Xen
>>> On 07.04.13 at 07:54, Zhenzhong Duan wrote:
> nmi isn't supported in dom0, fallback to general all cpu backtrace code.
Since when is sending NMIs not supported, and since when is this
Dom0-specific? If you want to deal with this, you should do so
properly: Special case sending NMIs in the res
>>> On 10.04.13 at 02:43, "H. Peter Anvin" wrote:
> OK, thinking about the GDT here.
>
> The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
> such, we probably don't want to allocate a full page to it for only
> that. This means that in order to create a readonly mapping we ha
>>> On 29.04.13 at 06:33, Alexander Gordeev wrote:
> --- a/drivers/iommu/irq_remapping.c
> +++ b/drivers/iommu/irq_remapping.c
> @@ -55,19 +55,19 @@ static int do_setup_msi_irqs(struct pci_dev *dev, int
> nvec)
> unsigned int irq;
> struct msi_desc *msidesc;
>
> - nvec = __round
>>> On 22.05.13 at 00:41, Konrad Rzeszutek Wilk wrote:
> On Tue, May 21, 2013 at 10:50:09PM +0100, Stefano Stabellini wrote:
>> We have to be careful about this: the point of PHYSDEVOP_get_free_pirq is
>> that Linux can know for sure the pirq that is going to be used to map the
>> MSI by QEMU. If
>>> On 22.05.13 at 17:14, Konrad Rzeszutek Wilk wrote:
> The physdev_unmap_pirq (from PHYSDEVOP_unmap_pirq), only has this
> check:
> if (domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND)
>
> and since the arch.hvm.emuirq is IRQ_UNBOUND (-1), it does not
> call unmap_domain_pirq_emuirq. It probably
>>> On 22.05.13 at 18:41, Konrad Rzeszutek Wilk wrote:
> On Wed, May 22, 2013 at 04:25:10PM +0100, Jan Beulich wrote:
>> Okay, that clarifies it quite a bit. For one, I'll leave any of the
>> emuirq stuff to Stefano, who wrote this originally. And then, from
>>
>>> On 28.05.13 at 20:22, David Vrabel wrote:
> +static int xen_pvclock_gtod_notify(struct notifier_block *nb, unsigned long
> unused,
> +void *priv)
> +{
> + static struct timespec last, next;
> + struct timespec now;
> + struct timekeeper *tk = priv;
>>> On 28.05.13 at 20:53, John Stultz wrote:
> On 05/28/2013 11:22 AM, David Vrabel wrote:
>> op.cmd = XENPF_settime;
>> -op.u.settime.secs = now->tv_sec;
>> -op.u.settime.nsecs = now->tv_nsec;
>> +op.u.settime.secs = now.tv_sec;
>> +op.u.settime.nsecs = now.tv_nsec;
>> o
>>> On 28.05.13 at 20:22, David Vrabel wrote:
> @@ -199,28 +201,59 @@ static void xen_get_wallclock(struct timespec *now)
>
> static int xen_set_wallclock(const struct timespec *now)
> {
> - struct xen_platform_op op;
> - int ret;
> -
> /* do nothing for domU */
> if (!xen_
the count to zero, triggering the necessary cleanup actions).
Also remove a misleading and a stale (after said commit) comment.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/blkback.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
--- 3.9-rc2/drivers/block/xen-blkback
This in particular re-does the compiler warning fix 9faec5b ("perf/x86:
Fix P6 driver section warning"), tightening the section attributes
rather than relaxing them.
Signed-off-by: Jan Beulich
Cc: Shaun Ruffell
Cc: yangyongqiang
Cc: Cyrill Gorcunov
Cc: Vince Weaver
---
arch/
Commit e44b7b7 ("x86: move suspend wakeup code to C") didn't care to
also eliminate the side effects that the earlier 4c49156 ("x86: make
arch/x86/kernel/acpi/wakeup_32.S use a separate") had, thus leaving a
now pointless, almost page size gap at the beginning of .text.
S
>>> On 06.08.12 at 00:28, "H. Peter Anvin" wrote:
> On 08/05/2012 02:29 PM, Jérôme Carretero wrote:
>> Hi,
>>
>> My PC (AMD Bulldozer + Asus SABERTOOTH 990FX) booted fine from UEFI
>> and it broke between v3.5 and v3.6-rc1.
>> Other machines with old BIOSes booted fine so I looked into EFI-related
>>> On 06.08.12 at 14:52, Matthew Garrett wrote:
> On Mon, Aug 06, 2012 at 07:44:34AM +0100, Jan Beulich wrote:
>
>> In any case, without having seen _how_ things break I don't
>> think a decision should be taken if/how to address this
>> (apparent) reg
>>> On 06.08.12 at 15:16, JérômeCarretero wrote:
> If it helps:
>
> - I can bisect the patch further down (might be a bit silly because
> I don't quite understand it),
> - you can suggest some modifications and at least I can test them
What would help most would be the full kernel log up to th
>>> On 07.08.12 at 01:29, JérômeCarretero wrote:
> On Mon, 06 Aug 2012 14:25:33 +0100
> "Jan Beulich" wrote:
>
>> >>> On 06.08.12 at 15:16, JérômeCarretero wrote:
>> > If it helps:
>> >
>> > - I can bisect the patch further
>>> On 07.08.12 at 05:06, JérômeCarretero wrote:
> On Mon, 6 Aug 2012 22:32:08 -0400
> Jérôme Carretero wrote:
>
>> For troubleshooting purposes I edited over your patch.
>> So far:
>> [...]
>> Maybe I can get more...
>
> With the following:
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/
>>> Alex Shi 08/22/12 5:24 AM >>>
>On 08/20/2012 10:12 PM, Jan Beulich wrote:
>I was thought you have 'Agreed' for xen part code. :)
I had agreed to it being done the right way, and I had pointed out the
problem once. I can't say for sure that I looked a
>>> Alex Shi 08/22/12 5:27 AM >>>
>> Second, the UV code doesn't flush the full range at all, it simply
>> ignores its 'end' parameter (and hence also the "all" indicator).
>
>Sure. the following rfc patch try to fix it. untested since no hardware.
Sure - this needs to be looked at by a person k
>>> On 22.08.12 at 10:54, Alex Shi wrote:
> On 08/22/2012 03:39 PM, Jan Beulich wrote:
>
>>>>> Alex Shi 08/22/12 5:24 AM >>>
>>> On 08/20/2012 10:12 PM, Jan Beulich wrote:
>>> I was thought you have 'Agreed' for xen part cod
>>> On 21.08.12 at 21:03, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 21, 2012 at 01:27:32PM -0400, Konrad Rzeszutek Wilk wrote:
>> Jan, I thought something odd. Part of this code replaces this:
>>
>> memblock_reserve(__pa(xen_start_info->mfn_list),
>> xen_start_info->pt_base - x
>>> On 21.08.12 at 21:03, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 21, 2012 at 01:27:32PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Aug 20, 2012 at 10:13:05AM -0400, Konrad Rzeszutek Wilk wrote:
>> > On Fri, Aug 17, 2012 at 06:35:12PM +0100, Stefano Stabellini wrote:
>> > > On Thu, 16 Aug 2
>>> Konrad Rzeszutek Wilk 08/22/12 9:05 PM >>>
>Thinking of just sticking this patch then:
Yeah, that may be best for the moment. Albeit I see no reason why you
shouldn't be able to use your more selective logic, just making it either
deal with only the pt_base == start-of-page-tables case (and f
FLUSH_MULTI. Then it causes some page can not
> be flushed from TLB.
>
> This patch fixed this issue.
>
> Reported-by: Jan Beulich
> Signed-off-by: Alex Shi
Acked-by: Jan Beulich
> ---
> arch/x86/xen/mmu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(
>>> On 24.08.12 at 20:17, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 24, 2012 at 04:16:39PM +0100, Jan Beulich wrote:
>> >>> On 24.08.12 at 10:55, Alex Shi wrote:
>> > While TLB_FLUSH_ALL gets passed as 'end' argument to
>> > flush_
>>> On 14.09.12 at 23:14, Linus Torvalds wrote:
> On Thu, Sep 13, 2012 at 11:23 PM, tip-bot for Jan Beulich
> wrote:
>>
>> x86: Prefer TZCNT over BFS
>
> This patch is insane.
I'm not going to defend this simple and strait forward a patch to
such a reply,
>>> On 17.09.12 at 12:00, Ingo Molnar wrote:
> Linus's suggestion is to introduce CONFIG_X86_TZCNT as an add-on
> patch that cleans up and documents what this is all about.
It wasn't just this he complained about. Plus I don't think the
suggested name fits the current scheme - it would imply the
>>> On 17.09.12 at 19:05, "H. Peter Anvin" wrote:
> Honestly, I don't see a reason to not do this unconditionally. On
> anything but (pre-686-era) extremely old CPUs the cost of the extra
> prefix is zero. On the really old CPUs the cost of the BSF instruction
> will dwarf the penalty cycle for
have worse performance than BSF.
Signed-off-by: Jan Beulich
Cc: Linus Torvalds
---
v2: Do this unconditionally, and change title accordingly.
---
arch/x86/include/asm/bitops.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 3.6-rc6/arch/x86/include/asm/bitops.h
+++ 3.6-rc6
y standard conformant - matching of
plain text tails cannot be checked by the caller (a patch to overcome
this will be sent shortly, and a follow-up patch for simplifying the
code is planned to be sent when that fixed went upstream).
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stu
ent suppression character '*'
(blindly discarding all succeeding non-white space from the format
and input strings),
- not honoring conversion specifiers for %n,
- not recognizing the C99 conversion specifier 't' (recognized by
vsprintf()).
Signed-
>>> On 19.09.12 at 12:51, Oliver Chick wrote:
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an o
Without ARCH_REQUIRE_GPIOLIB there's no reason to force this code, when
enabled, to always be built into the kernel, which requires only minor
Makefile and source code adjustments.
Signed-off-by: Jan Beulich
Cc: Ryan Mallon
---
v2: Make gpiolib_init() static. Properly handle !CONFIG_DEB
would deny the request since we do not have access to the
> Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
> 0x80140.
>
> CC: sta...@kernel.org
> Fixes-Oracle-Bugzilla:
> https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
> Signed-off-by: Konrad Rzes
>>> On 20.09.12 at 10:51, Oliver Chick wrote:
> Ah yes, you're right - rings can accomodate 64 requests. ijc, and myself
> got muddled. It also explains the comment in my summary that we only use
> the first 60-ish persistent grants!
>
> With multipage rings, this will probably become a function,
>>> On 20.09.12 at 13:30, Oliver Chick wrote:
> The memory overhead, and fallback mode points are related:
> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> per device. I made a mistake (pointed out by Jan) as the maximum number
> of requests that can fit into a single-page
e on Intel CPUs (intel.c's
instance was lacking the sentinel with family being zero), so the
patch bumps that by one,
- c_models' vendor sub-field was unused (and anyway redundant with
the base structure's c_x86_vendor field), so the patch deletes it.
Signed-off-by: Jan Beul
>>> On 20.09.12 at 15:49, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> >>> On 20.09.12 at 13:30, Oliver Chick wrote:
>> > The memory overhead, and fallback mode points are related:
>> > -Firstly, it t
>>> On 20.09.12 at 16:13, Oliver Chick wrote:
> 3) Having blkback inform blkfront on startup as to how many grefs it is
> willing to persistently-map. We then hit the same question again though:
> what should be do if blkfront ignores this limit?
Not really - if any information coming from the ba
>>> On 07.08.12 at 11:30, Matt Fleming wrote:
> On Tue, 2012-08-07 at 08:14 +0100, Jan Beulich wrote:
>> That's not surprising. The question really is what goes wrong
>> when the call is being made - page fault, some other fault, or
>> silent hang. A page fault
>>> On 09.08.12 at 17:03, "Kirill A. Shutemov"
>>> wrote:
> From: Andi Kleen
>
> Add a cache avoiding version of clear_page. Straight forward integer variant
> of the existing 64bit clear_page, for both 32bit and 64bit.
While on 64-bit this is fine, I fail to see how you avoid using the
SSE2 i
>>> On 09.08.12 at 17:03, "Kirill A. Shutemov"
>>> wrote:
> ENTRY(clear_page_nocache)
> CFI_STARTPROC
> - xorl %eax,%eax
> - movl $4096/64,%ecx
> + push %rdi
> + call kernel_fpu_begin
> + pop%rdi
You use CFI annotations elsewhere, so why don't you use
pushq
>>> On 13.08.12 at 13:43, "Kirill A. Shutemov"
>>> wrote:
> On Thu, Aug 09, 2012 at 04:22:04PM +0100, Jan Beulich wrote:
>> >>> On 09.08.12 at 17:03, "Kirill A. Shutemov"
>> >>> wrote:
>
> ...
>
>>
>I cannot see any other way out of this than to loose all the newly added
>consts. We have to different behavior across platforms to find a suitable
>solution that is reliable.
>
>[Kept rest of mail as I added Jan - hope he have some ideas to throw in].
I'd first of all need a better understanding
>Al posted the following:
>
>; cat >a.c <<'EOF'
>const char foo[] __attribute__ ((__section__(".blah"))) = "";
>const char * const bar __attribute__((__section__(".blah"))) = "";
>EOF
>; gcc -m32 -S a.c
>; gcc -m64 -S a.c
>a.c:2: e
>>> On 06.07.12 at 23:38, Yinghai Lu wrote:
> On Fri, Jul 6, 2012 at 7:14 AM, Jan Beulich wrote:
>> Needing to deal with potentially large memory configurations, the
>> variables here should be "unsigned long" instead of "unsigned int".
>>
>
>>> On 06.07.12 at 23:38, Yinghai Lu wrote:
> On Fri, Jul 6, 2012 at 7:14 AM, Jan Beulich wrote:
>> Needing to deal with potentially large memory configurations, the
>> variables here should be "unsigned long" instead of "unsigned int".
>>
>
>>> On 07.07.12 at 00:02, Yinghai Lu wrote:
> On Fri, Jul 6, 2012 at 7:18 AM, Jan Beulich wrote:
>> Now that the x86_phys_bits cpuinfo field is uniformly available on
>> 32- and 64-bit, the function no longer needs to determine this anew.
>>
>> Additionally,
>>> Andi Kleen 08/19/12 5:02 AM >>>
>-extern const unsigned long kallsyms_addresses[] __attribute__((weak));
>-extern const u8 kallsyms_names[] __attribute__((weak));
>+extern __visible const unsigned long kallsyms_addresses[]
>__attribute__((weak));
>+extern __visible const u8 kallsyms_names[] _
>>> Andi Kleen 08/19/12 4:58 AM >>>
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -224,8 +224,9 @@ config X86_32_LAZY_GS
>
>config ARCH_HWEIGHT_CFLAGS
>string
>-default "-fcall-saved-ecx -fcall-saved-edx" if X86_32
>-default "-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
>
>>> Andi Kleen 08/19/12 4:59 AM >>>
>I verified this generates the same binary (on 64bit) as the original
>register variable.
This isn't very surprising given that the modified code is inside a
CONFIG_X86_32 conditional (as ought to be obvious from the code using
%%esp). Given that it's being use
>>> Andi Kleen 08/19/12 5:05 AM >>>
>Work around a LTO gcc problem: when there is no reference to a variable
>in a module it will be moved to the end of the program. This causes
>reordering of initcalls which the kernel does not like.
>Add a dummy reference function to avoid this. The function is
>>> Andi Kleen 08/19/12 4:59 AM >>>
>@@ -1904,6 +1904,10 @@ static int simplify_symbols(struct module *mod, const
>struct load_info *info)
>
>switch (sym[i].st_shndx) {
>case SHN_COMMON:
>+/* Ignore common symbols */
>+if (!strncmp(name, "__gnu_lto", 9))
>
>>> On 19.08.12 at 17:15, Andi Kleen wrote:
>> >--- a/arch/x86/include/asm/arch_hweight.h
>> >+++ b/arch/x86/include/asm/arch_hweight.h
>> >@@ -25,9 +25,14 @@ static inline unsigned int __arch_hweight32(unsigned int
>> >w)
>> >{
>> >unsigned int res = 0;
>> >
>> >+#ifdef CONFIG_LTO
>> >+
>>> On 19.08.12 at 17:01, Andi Kleen wrote:
> On Sun, Aug 19, 2012 at 09:46:04AM +0100, Jan Beulich wrote:
>> >>> Andi Kleen 08/19/12 5:05 AM >>>
>> >Work around a LTO gcc problem: when there is no reference to a variable
>> >in a module i
201 - 300 of 1374 matches
Mail list logo
