>>> On 19.03.13 at 15:32, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 18, 2013 at 05:49:32PM +0100, Roger Pau Monne wrote:
>> dev_bus_addr returned in the grant ref map operation is the mfn of the
>> passed page, there's no need to store it in the persistent grant
>> entry, since we can always get
>>> On 19.03.13 at 16:10, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 19, 2013 at 02:55:56PM +, Jan Beulich wrote:
>> >>> On 19.03.13 at 15:32, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > @@ -971,7 +962,7 @@ static int
>>> On 20.03.13 at 21:52, "H. Peter Anvin" wrote:
> On 03/20/2013 01:42 PM, Shawn Starr wrote:
>> Hello folks,
>>
>> I was looking at why I can't load the Intel RNG driver (or why it doesn't
> load automatically) and
>> it just so happens I have both the mobile and non-mobile ICH9 chipset.
> L
te to assigning the device to guests anyway.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/xen/hypercall.h |4 +-
drivers/xen/fallback.c |3 +
drivers/xen/xen-pciback/pci_stub.c | 59 ++-
include/xen/interface/physdev.h |6 +++
4
>>> On 06.02.13 at 18:12, Konrad Rzeszutek Wilk wrote:
>> +if (pci_find_capability(dev, PCI_CAP_ID_MSIX)) {
>> +struct physdev_pci_device ppdev = {
>> +.seg = pci_domain_nr(dev->bus),
>> +.bus = dev->bus->number,
>> +.devf
m req->u.rw.handle
>> rather than the actual device.
>>
>> Signed-off-by: Chen Gang
>> Acked-by: Jan Beulich
>
> Sorry I'm a bit late but since since 01c681d is in stable, I guess
> a72d900 (xen/xen-blkback: preq.dev is used without initialized)
>
>>> On 03.04.13 at 15:25, William Dauchy wrote:
> On Wed, Apr 3, 2013 at 3:01 PM, Jan Beulich wrote:
>> Iirc we requested the earlier commit to be removed from stable
>> trees, and I think Greg also did so.
>
> I'm sorry but I'm unable to find a reve
>>> On 03.04.13 at 15:56, William Dauchy wrote:
> On Wed, Apr 3, 2013 at 3:42 PM, Jan Beulich wrote:
>> ChangeLog-3.8.3 for example has
>
> oh sorry, you are right. I wasn't looking is the 3.8.x branch.
> The thing is, the revert seems present only in 3.8.x br
ot;targets" instead, thus allowing the assignment
at the top of the file to be shrunk quite a bit.
At the same time, remove a pointless flags override line - the variable
assigned to was misspelled anyway, and the options added are
meaningless for assembly sources.
Signed-off-by: Jan Beulich
For quite a few Xen versions, this wasn't the IRQ vector anymore
anyway, and it is not being used by the kernel for anything. Hence
drop the field from struct irq_info, and respective function
parameters.
Signed-off-by: Jan Beulich
Cc: Stefano Stabellini
---
arch/x86/pci/xen.c |
aving noticed,
I wouldn't think so. Nor would I see a strong need for this to go into
3.9.
Jan
> Jan Beulich wrote:
>
>>eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence
>>their .cmd files don't get included by the build machin
>>> On 28.01.13 at 18:44, Stefano Stabellini
>>> wrote:
> I think that Olaf made his point very clear: a feature A should only be
> enabled if the corresponding flag A is set.
> In fact it seems to me that this patch is correct on its own merits,
> regardless of Xen does or does not.
>
> The Xen
al fix, so likely this can be
taken to count as an ack from him.
Reported-by: Peter Moody
Signed-off-by: Jan Beulich
Cc: sta...@vger.kernel.org
Cc: Konrad Rzeszutek Wilk
Cc: David Vrabel
Tested-by: Peter Moody
---
arch/x86/ia32/ia32entry.S |4 ++--
1 file changed, 2 insertions(+), 2
>>> On 30.01.13 at 01:51, "K. Y. Srinivasan" wrote:
> Xen emulates Hyper-V to host enlightened Windows. Looks like this
> emulation may be turned on by default even for Linux guests. Check and
> fail Hyper-V detection if we are on Xen.
>
> Signed-off-by: K. Y. Srinivasan
> ---
> arch/x86/kernel
>>> On 30.01.13 at 01:51, "K. Y. Srinivasan" wrote:
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -14,10 +14,15 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
> +#include
> +#include
> +
>>> On 30.01.13 at 19:12, KY Srinivasan wrote:
> Presumably, Hyper-V emulation is only to run enlightened Windows. The issue
> with
> Xen is not that it emulates Hyper-V, but this emulation is turned on while
> running Linux.
> That is the reason I chose to check for Xen. Would you prefer a DMI
>>> On 31.01.13 at 16:53, KY Srinivasan wrote:
> Are there any published standards in terms of how the CPUID space should be
> populated in the range from 0x4000 to 0x4001. Specifically, unless
I recall having seen this range being marked as reserved for
hypervisor use somewhere, but I
>>> On 24.01.13 at 02:17, "K. Y. Srinivasan" wrote:
> @@ -69,6 +74,11 @@ static void __init ms_hyperv_init_platform(void)
> ms_hyperv.features, ms_hyperv.hints);
>
> clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
> +
> + /*
> + * Setup the IDT for hypervisor c
>>> On 23.01.13 at 21:00, Steven Rostedt wrote:
> On Mon, 2012-11-05 at 08:58 +, Jan Beulich wrote:
>> >>> On 02.11.12 at 20:19, Steven Rostedt wrote:
>> > @@ -1842,8 +1851,12 @@ nmi_swapgs:
>> >SWAPGS_UNSAFE_STACK
>> > nmi_restore:
While in one case a plain annotation is necessary, in the other case
the stack adjustment can simply be folded into the immediately
preceding RESTORE_ALL, thus getting the correct annotation for free.
Signed-off-by: Jan Beulich
Cc: Steven Rostedt
---
arch/x86/kernel/entry_64.S |7
>>> On 24.01.13 at 17:07, KY Srinivasan wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, January 24, 2013 3:48 AM
>> To: KY Srinivasan
>> Cc: o...@aepfle.de; b...@alien8.de; a...@canonical.com;
>>> On 24.01.13 at 20:04, "H. Peter Anvin" wrote:
> Can't you discover Xen emulation by looking for Xen first? Or does Xen go
> "stealth"?
That's already being done - the ordering currently is Xen, VMWare,
Hyper-V, KVM. I.e. there's only a problem when !CONFIG_XEN_PVHVM.
Jan
--
To unsubscribe
>>> On 24.01.13 at 20:10, "H. Peter Anvin" wrote:
> I also have to point out the obvious problem with Xen masquerading as HyperV
> without implementing the same feature set...
I can't resist to state that this is what feature bits have been
introduced for in CPUID leaves. As long as Xen's shim d
>>> On 24.01.13 at 20:03, KY Srinivasan wrote:
> I was under the impression that only Dom0 Xen would emulate Hyper-V.
How that? It's the hypervisor that does the emulation, and obviously
not for Dom0, but for (HVM) DomU-s.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-k
>>> On 24.01.13 at 19:59, Olaf Hering wrote:
> On Thu, Jan 24, KY Srinivasan wrote:
>
>
>> > Question is - considering you stated that this is supported
>> > starting in Win8, doesn't Hyper-V itself announce that
>> > capability in some explicit way?
>>
>> Thanks Jan. Unfortunately I don't thin
>>> On 24.01.13 at 23:28, Josh Triplett wrote:
> On Thu, Jan 24, 2013 at 12:34:21PM -0800, tip-bot for Jan Beulich wrote:
>> Commit-ID: 13f0e4d2b9e2209f13d5a4122478eb79e6136870
>> Gitweb:
> http://git.kernel.org/tip/13f0e4d2b9e2209f13d5a4122478eb79e6136870
>>> On 24.01.13 at 18:32, "H. Peter Anvin" wrote:
> On 01/24/2013 11:15 AM, Ingo Molnar wrote:
>>
>> * Jan Beulich wrote:
>>
>>> v2 of this series is merely updated on top of the changes between
>>> 3.6 and 3.7-rc (which includes the
>>> On 25.01.13 at 23:11, "H. Peter Anvin" wrote:
> On 01/25/2013 02:43 AM, tip-bot for Jan Beulich wrote:
>> Commit-ID: 05fbf4d6fc6a3c0c3e63b77979c9311596716d10
>> Gitweb:
> http://git.kernel.org/tip/05fbf4d6fc6a3c0c3e63b77979c9311596716d10
>>
>>> On 27.01.13 at 16:50, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
>> On Fri, Jan 25, 2013 at 11:53 PM, Wang YanQing wrote:
>> > I get below warning every day with 3.7,
>> > one or two times per day.
>> >
>> > [ 2235.186027] WARNING: at
> /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.
>>> On 25.01.13 at 19:43, Konrad Rzeszutek Wilk wrote:
> @@ -764,6 +768,9 @@ __do_block_io_op(struct xen_blkif *blkif)
> rp = blk_rings->common.sring->req_prod;
> rmb(); /* Ensure we see queued requests up to 'rp'. */
>
> + if (RING_REQUEST_PROD_OVERFLOW(&blk_rings->common, rp, r
'handle' value is superfluous
> so lets not do it.
>
> Cc: sta...@vger.kernel.org
Is this really stable material? It fixes nothing but the (wrong)
impression that the driver might be using frontend provided data
without checking.
Jan
> Acked-by: Jan Beulich
> Acked-by: Ian Campbell
>>> On 28.01.13 at 16:42, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 28, 2013 at 11:07:46AM +, Jan Beulich wrote:
>> >>> On 25.01.13 at 19:43, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > @@ -764,6 +768,9 @@ __do_block_io_op(struct xen
>>> On 27.02.13 at 05:52, Chen Gang wrote:
> if call xen_vbd_translate failed, the preq.dev will be not initialized.
> so use blkif->vbd.pdevice instead (still better to print relative info).
>
> Signed-off-by: Chen Gang
Acked-by: Jan Beulich
> ---
> drive
>>> On 27.02.13 at 05:52, Chen Gang wrote:
> if call xen_vbd_translate failed, the preq.dev will be not initialized.
> so use blkif->vbd.pdevice instead (still better to print relative info).
You also could have mentioned that even before commit
01c681d4c70d64cb72142a2823f27c4146a02e63 the v
>>> On 27.02.13 at 10:50, Roger Pau Monné wrote:
> On 27/02/13 05:52, Chen Gang wrote:
>>
>> if call xen_vbd_translate failed, the preq.dev will be not initialized.
>> so use blkif->vbd.pdevice instead (still better to print relative info).
>
> preq.dev is initialized a a couple of lines prio
>>> On 27.02.13 at 11:38, Chen Gang wrote:
> 于 2013年02月27日 17:57, Jan Beulich 写道:
>> You also could have mentioned that even before commit
>> 01c681d4c70d64cb72142a2823f27c4146a02e63 the value printed
>> here was bogus, as it was the guest provided value from
>&
>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
> This series contains the initial implementation of indirect
> descriptors for Linux blkback/blkfront.
>
> Patches 1, 2, 3, 4 and 5 are bug fixes and minor optimizations.
>
> Patch 6 contains a LRU implementation for blkback that will be needed
>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
> dev_bus_addr returned in the grant ref map operation is the mfn of the
> passed page, there's no need to store it in the persistent grant
> entry, since we can always get it provided that we have the page.
Interesting that you come up with this,
>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
> Moving grant ref handles from blkbk to pending_req will allow us to
> get rid of the shared blkbk structure.
At the expense of (slightly?) higher memory requirements?
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/
>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
> @@ -122,6 +125,19 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
> spin_lock_init(&blkif->free_pages_lock);
> INIT_LIST_HEAD(&blkif->free_pages);
> blkif->free_pages_num = 0;
> + blkif->pending_reqs = kzalloc(size
>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
> @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t;
> */
> #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>
> +#define BLKIF_MAX_INDIRECT_GREFS_PER_REQUEST 8
> +
> +struct blkif_request_segment_aligned {
> + grant_ref_t gref;/* refer
>>> On 28.02.13 at 12:25, Roger Pau Monné wrote:
> This is the expanded graph that also contains indirect descriptors
> without persistent grants:
>
> http://xenbits.xen.org/people/royger/plot_indirect_nopers.png
Thanks. Interesting - this suggests an unexpectedly high hit rate.
Jan
--
To unsub
>>> On 28.02.13 at 13:00, Roger Pau Monné wrote:
> On 28/02/13 12:19, Jan Beulich wrote:
>>>>> On 28.02.13 at 11:28, Roger Pau Monne wrote:
>>> @@ -109,6 +111,16 @@ typedef uint64_t blkif_sector_t;
>>> */
>>> #defin
>>> On 19.02.13 at 06:53, David Miller wrote:
> From: Andrew Jones
> Date: Mon, 18 Feb 2013 21:29:20 +0100
>
>> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does
>> a xenvif_put(). As callers of netbk_fatal_tx_err should only
>> have one reference to the vif at this time, then the xenv
>>> On 21.02.13 at 18:16, Ian Campbell wrote:
> On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote:
>> On ARM we want these to be the same size on 32- and 64-bit.
>>
>> This is an ABI change on ARM. X86 does not change.
>>
>> Signed-off-by: Ian
>>> On 22.02.13 at 09:28, Ian Campbell wrote:
> On Fri, 2013-02-22 at 08:12 +, Jan Beulich wrote:
>> >>> On 21.02.13 at 18:16, Ian Campbell wrote:
>> > On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote:
>> >> On ARM we want these to be th
>>> On 22.02.13 at 09:55, Ian Campbell wrote:
> On Fri, 2013-02-22 at 08:48 +, Jan Beulich wrote:
>> >>> On 22.02.13 at 09:28, Ian Campbell wrote:
>> > On Fri, 2013-02-22 at 08:12 +, Jan Beulich wrote:
>> >> >>> On 21.02.13 at 18:
>>> On 22.02.13 at 17:19, Greg KH wrote:
> On Fri, Feb 22, 2013 at 10:46:45AM -0500, Konrad Rzeszutek Wilk wrote:
>> Hey Greg,
>>
>> Please put git commit 51ac8893a7a51b196501164e645583bf78138699
>> commit 51ac8893a7a51b196501164e645583bf78138699
>> Au
te to assigning the device to guests anyway.
This is the kernel part of hypervisor side commit 4245d33 ("x86/MSI:
add mechanism to fully protect MSI-X table from PV guest accesses") on
the master branch of git://xenbits.xen.org/xen.git.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/
>>> On 12.03.13 at 16:06, "Jan Beulich" wrote:
> For MSI-X capable devices the hypervisor wants to write protect the
> MSI-X table and PBA, yet it can't assume that resources have been
> assigned to their final values at device enumeration time. Thus have
> pci
>>> On 05.09.12 at 07:34, Alex Shi wrote:
> On 08/25/2012 03:45 AM, Jan Beulich wrote:
>>>>> On 24.08.12 at 20:17, Konrad Rzeszutek Wilk
>>>>> wrote:
>>> How can I reproduce this
>>
>> I don't know, I spotted this while loo
>>> On 11.09.12 at 08:17, Ryan Mallon wrote:
> On 10/09/12 22:16, Jan Beulich wrote:
>> +#ifdef MODULE
>> +int __init gpiolib_init(void)
>
> Should be static.
Oh, yes, of course.
>> +{
>> +return gpiolib_sysfs_init() ?: gpiolib_debugfs_ini
>>> On 11.09.12 at 19:38, Linus Walleij wrote:
> On Mon, Sep 10, 2012 at 2:16 PM, Jan Beulich wrote:
>> +#ifndef MODULE
>> subsys_initcall(gpiolib_debugfs_init);
>> +#endif
>>
>> #endif /* DEBUG_FS */
>> +
>> +#ifdef MODULE
>
>>> On 12.09.12 at 19:41, Randy Dunlap wrote:
> On 09/12/2012 12:43 AM, Jan Beulich wrote:
>>>>> On 11.09.12 at 19:38, Linus Walleij wrote:
>>> On Mon, Sep 10, 2012 at 2:16 PM, Jan Beulich wrote:
>>>> + return gpiolib_sysfs_init() ?: gp
>>> On 02.10.12 at 12:44, Stefano Stabellini
>>> wrote:
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus
>> nostackp := $(call cc-option, -fno-stack-protector)
>> CFLAGS_features.o := $(nostackp)
>>
>> + obj-$(CO
>>> On 02.10.12 at 13:45, Stefano Stabellini
>>> wrote:
>> > Considering that dbgp doesn't seem to be very useful without PCI at the
>> > moment, could we just turn it into:
>> >
>> > dom0-$(CONFIG_PCI) += dbgp.o
>> >
>> > ?
>>
>> Better not - the code is specifically not PCI-only. And I can't
>>> On 02.10.12 at 14:55, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 02, 2012 at 12:54:20PM +0100, Jan Beulich wrote:
>> >>> On 02.10.12 at 13:45, Stefano Stabellini
>> >>>
> wrote:
>> >> > Considering that dbgp doesn't seem t
>>> On 01.10.12 at 10:37, Hugh Dickins wrote:
> I noticed yesterday that the DirectMap counts at the bottom of x86_64's
> /proc/meminfo are wrong on v3.5 and v3.6. For example, I happen to have
> booted this laptop with mem=700M to run a test, but /proc/meminfo shows
>
> DirectMap4k:4096
>>> On 02.10.12 at 17:13, Stefano Stabellini
>>> wrote:
> This patch is actually a merge conflict resolution between Konrad's Xen
> tree and the following commit:
>
> commit 9fa5780beea1274d498a224822397100022da7d4
> Author: Jan Beulich
> Date: Tu
>>> Matt Fleming 10/03/12 2:59 PM >>>
>+static int insert_identity_mapping(resource_size_t paddr, unsigned long vaddr,
>+unsigned long size)
>+{
>+unsigned long end = vaddr + size;
>+unsigned long next;
>+pgd_t *vpgd, *ppgd;
>+
>+#ifdef CONFIG_X86_32
>+ppgd = in
>>> On 03.10.12 at 16:03, Matt Fleming wrote:
> On Wed, 2012-10-03 at 14:31 +0100, Jan Beulich wrote:
>> >>> Matt Fleming 10/03/12 2:59 PM >>>
>> >@@ -163,6 +258,10 @@ static void __iomem *__ioremap_caller(resource_size_t
>> >phys_add
>>> On 03.10.12 at 19:08, Stefano Stabellini
wrote:
> Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm:
> initial Xen support") PV on HVM guests can be xen_initial_domain.
> However PV on HVM guests might have an unitialized xen_start_info, so
> check before accessing its fields.
>>> On 04.10.12 at 11:18, Matt Fleming wrote:
> On Thu, 2012-10-04 at 07:32 +0100, Jan Beulich wrote:
>> Btw., once this set of yours is in - will I need to resubmit the
>> time handling patch that actually triggered this work, or will
>> you just reinstate it wit
>>> On 25.09.12 at 19:53, David Vrabel wrote:
> @@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info)
>
> mutex_lock(&bdev->bd_mutex);
>
> - if (bdev->bd_openers) {
> + /* If the backend is already CLOSED, close now. */
> + if (bdev->bd_openers && backend_state !
ouldn't be done during memory hot add.
Hence, re-add the removed increments of "pages", but make them and the
one in phys_pte_init() conditional upon !after_bootmem.
Reported-by: Hugh Dickins
Signed-off-by: Jan Beulich
---
Not sure if this ought to be copied to stable@.
---
arc
>>> On 04.10.12 at 23:08, "H. Peter Anvin" wrote:
> On 10/03/2012 06:31 AM, Jan Beulich wrote:
>>>>> Matt Fleming 10/03/12 2:59 PM >>>
>>> +static int insert_identity_mapping(resource_size_t paddr, unsigned long
> vaddr,
>>> +
>>> On 05.10.12 at 08:48, Matt Fleming wrote:
> On Fri, 2012-10-05 at 07:39 +0100, Jan Beulich wrote:
>> >>> On 04.10.12 at 23:08, "H. Peter Anvin" wrote:
>> > On 10/03/2012 06:31 AM, Jan Beulich wrote:
>> >>>>> Matt Flemi
>>> On 05.10.12 at 13:42, David Vrabel wrote:
> On 02/10/12 21:02, Konrad Rzeszutek Wilk wrote:
>> On Mon, Oct 01, 2012 at 06:19:19PM +0100, David Vrabel wrote:
>>> On 25/09/12 18:53, David Vrabel wrote:
On 21/09/12 17:04, David Vrabel wrote:
> From: David Vrabel
>
> Backend driv
tforms, but we can
> easily adopt the 64-bit scheme if one is discovered.
>
> v2: Based on feedback from Jan Beulich delete the 32-bit changes in
> [PATCH 1/3], they were likely to create more problems than they would
> solve and the identity I/O mappings are unused on 32-bit anyway.
&g
>>> On 23.10.12 at 20:12, Konrad Rzeszutek Wilk wrote:
Do you really want to target 3.8 for these, without any hypervisor
side review having happened? In particular,
> Changelog [since v4]
> - Mukesh addressed the reviewer's concerns.
> - Took Mukesh's patches and redid the changelogs.
> - Ad
>>> On 23.10.12 at 20:50, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 23, 2012 at 08:09:27PM +0200, Roger Pau Monné wrote:
>> On 23/10/12 19:20, Konrad Rzeszutek Wilk wrote:
>> diff --git a/drivers/block/xen-blkback/blkback.c
> b/drivers/block/xen-blkback/blkback.c
>> index c6decb9..2b98
>>> On 24.10.12 at 11:34, Ian Campbell wrote:
> On Wed, 2012-10-24 at 08:13 +0100, Jan Beulich wrote:
>
>> > include/xen/interface/memory.h | 29 ++-
>> > include/xen/interface/physdev.h | 10 ++
>>
>> ... any changes to the hyperv
>>> On 24.10.12 at 23:33, Randy Dunlap wrote:
> On 10/23/2012 09:19 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 201201023:
>>
>
> on x86_64:
>
> drivers/built-in.o: In function `dbgp_reset_prep':
> (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep'
> drivers/built-
>>> On 25.10.12 at 11:04, Olaf Hering wrote:
> @@ -1495,38 +1494,53 @@ asmlinkage void __init xen_start_kernel(void)
> #endif
> }
>
> -void __ref xen_hvm_init_shared_info(void)
Was the __ref here in fact unnecessary (i.e. did you check that
its removal doesn't cause any section mismatch warni
>>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote:
>> On Thu, 25 Oct 2012, Jan Beulich wrote:
>> > >>> On 24.10.12 at 23:33, Randy Dunlap wrote:
>> > > On 10/23/2012 09:19 PM
>>> "Liu, Jinsong" 10/26/12 8:18 AM >>>
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +.name = "processor_aggregator",
>> +.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +.ids = pad_device_ids,
>> +.ops = {
>> +.add = xen_acpi_pad_add,
>
>.remove?
>
>[Jinsong] .rem
>>> On 25.10.12 at 14:19, "Liu, Jinsong" wrote:
> --- /dev/null
> +++ b/drivers/xen/xen_acpi_pad.c
> @@ -0,0 +1,173 @@
> +/*
> + * xen_acpi_pad.c - Xen pad interface
> + *
> + * Copyright (c) 2012, Intel Corporation.
> + *Author: Liu, Jinsong
> + *
> + * This program is free software; you can
>>> Alan Stern 11/01/12 4:28 PM >>>
>On Wed, 31 Oct 2012, Randy Dunlap wrote:
>> on x86_64:
>>
>> drivers/built-in.o: In function `ehci_reset':
>> host.c:(.text+0x542a7e): undefined reference to `dbgp_reset_prep'
>> host.c:(.text+0x542b75): undefined reference to `dbgp_external_startup'
>> driver
>>> Steven Rostedt 11/01/12 2:04 AM >>>
>On Mon, 2012-10-01 at 17:29 -0700, Salman Qazi wrote:
>> @@ -1826,12 +1832,15 @@ repeat_nmi:
>> * is benign for the non-repeat case, where 1 was pushed just above
>> * to this very stack slot).
>> */
>> -movq $1, 5*8(%rsp)
>> +movq
efined reference to `xen_dbgp_external_startup'
>
>There is another patch that needs to be Acked and picked up by
>Greg KH that fixes this.
>
>Let me poke Jan Beulich to repost it with the appropiate Acks.
It's been picked up already, but another dependency problem was f
>>> Alan Stern 11/01/12 9:39 PM >>>
>On Thu, 1 Nov 2012, Jan Beulich wrote:
>> >>> Alan Stern 11/01/12 4:28 PM >>>
>> >Evidently we need to change your new test in
>> >drivers/usb/early/ehci-dbgp.c to:
>> >
>
>>> On 01.11.12 at 23:05, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 01, 2012 at 08:04:58PM +, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 11/01/12 1:49 PM >>>
>> >On Wed, Oct 31, 2012 at 10:42:30PM -0700, David Rientjes wrote:
>> &
While these got added in the right place everywhere else, entry_64.S
is the odd one where they ended up before the initial CFI directive(s).
In order to cover the full code ranges, the CFI directive must be
first, though.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/entry_64.S | 14
At least some older gcc versions dislike mixing constant and non-const
data in the same section ("... causes a section type confict").
Signed-off-by: Jan Beulich
---
arch/x86/kernel/cpu/perf_event_p6.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.7-rc3/arch/x86/
setup_hpet_msi_remapped() returns a negative error indicator on error
- check for this rather than for a boolean false indication, and pass
on that error code rather than a meaningless "-1".
Signed-off-by: Jan Beulich
Cc: David Woodhouse
---
arch/x86/kernel/apic/io_apic.c |5 +++
HPET_TN_FSB is not a proper mask bit; it merely toggles between MSI and
legacy interrupt delivery. The proper mask bit is HPET_TN_ENABLE, so
use both bits when (un)masking the interrupt.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/hpet.c |4 ++--
1 files changed, 2 insertions
>>> On 02.11.12 at 15:01, Alan Stern wrote:
> On Thu, 1 Nov 2012, Jan Beulich wrote:
>
>> >>> Alan Stern 11/01/12 9:39 PM >>>
>> >On Thu, 1 Nov 2012, Jan Beulich wrote:
>> >> >>> Alan Stern 11/01/12 4:28 PM >>>
>
>>> On 02.11.12 at 14:53, Steven Rostedt wrote:
> On Fri, 2012-11-02 at 09:51 -0400, Steven Rostedt wrote:
>> On Thu, 2012-11-01 at 19:53 +, Jan Beulich wrote:
>>
>> > There doesn't appear to be anything special about these adjustments, so I
>>
virtualization friendly
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 FAQ at http://www.tux.org/lkml/
Besides folding duplicate code, this has the advantage of fixing
x86-64's failure to use proper (para-virtualizable) accessors for
dealing with CR0.TS.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/xor.h| 319 +-
arch/x86/include/asm/xor
On CPUs with 64-byte last level cache lines, this yields roughly 10%
better performance, independent of CPU vendor or specific model (as far
as I was able to test).
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/xor.h| 172 ++
arch/x86/include
in that case.
For consistency, pull into the shared (32- and 64-bit) header not only
the inclusion of the generic code, but also that of the AVX variants.
Signed-off-by: Jan Beulich
Cc: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/xor.h|8 +++-
arch/x86/include/asm/xor_32.h
1: simplify and tighten parsing of device IDs
2: reject out of range inputs
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
well formed).
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c | 83 +
1 file changed, 39 insertions(+), 44 deletions(-)
--- 3.7-rc3-xen-pciback.orig/drivers/xen/xen-pciback/pci_stub.c
+++ 3.7-rc3-xen-pciback/drivers/xen/xen-pciback/pci_s
nd part is cosmetic only, as the kernel's sscanf()
currently ignores the field widths, but a patch to overcome this is on
its way.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c | 39 +
1 file changed, 27 insertions(+), 12 deletions(-)
necessary to meet the caller's request.
Also fail on negative field widths.
Signed-off-by: Jan Beulich
---
lib/vsprintf.c | 96 +++--
1 file changed, 53 insertions(+), 43 deletions(-)
--- 3.7-rc3/lib/vsprintf.c
+++ 3.7-rc3-sscanf-field-widt
This makes the resulting diagnostics quite a bit more useful.
Signed-off-by: Jan Beulich
---
include/linux/bug.h | 16
1 file changed, 16 insertions(+)
--- 3.7-rc3/include/linux/bug.h
+++ 3.7-rc3-static-assert/include/linux/bug.h
@@ -27,8 +27,15 @@ struct pt_regs
>>> On 02.11.12 at 17:44, Konrad Rzeszutek Wilk wrote:
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -359,18 +359,14 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t
> new_val,
> return _hypercall4(int, update_va_mapping, va,
>
>>> On 04.11.12 at 14:26, Namit Gupta wrote:
> API simple_strtol() and simple_strtoul() are giving incorrect result for
> string "-".
> These API's consider "-" as a '-' (negative integer) and return incorrect
> string pointer.
> The API returns pointer next to '-' character. However it should ret
>>> On 03.11.12 at 13:16, "Liu, Jinsong" wrote:
> Konrad Rzeszutek Wilk wrote:
From f514b97628945cfac00efb0d456f133d44754c9d Mon Sep 17 00:00:00
2001
>>> From: Liu, Jinsong
>>> Date: Thu, 1 Nov 2012 21:02:36 +0800
>>> Subject: [PATCH 1/2] Xen acpi pad implement
>>>
>>> PAD is acpi Pro
1 - 100 of 1374 matches
Mail list logo
