On Mon, Jul 30, 2012 at 03:14:28PM +0800, majianpeng wrote:
> When exec bio_alloc, the bi_rw is zero.But after calling bio_add_page,
What about submit_bio? That sets the bi_rw as well?
> it will use bi_rw.
> Fox example, in functiion __bio_add_page,it will call merge_bvec_fn().
function.
> The me
Which allows us to be a bit smarter in case we exhaust the reserved
virtual space.
[v1: Suggested by Ian Campbell]
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/enlighten.c |2 ++
arch/x86/xen/mmu.c |5 -
arch/x86/xen/p2m.c | 35
The callers of this function (dmi_alloc) and the various
Xen related ones can deal with a NULL pointer.
Suggested-by: Ian Campbell
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/kernel/setup.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel
than enough to cover. If we do
run over that number, the code is smart enough to stop and not
allocate anymore leafs.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/p2m.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
In v3.5 I've added some patches that during boot-time and add more
entries to the P2M tree:
http://lists.xen.org/archives/html/xen-devel/2012-04/msg01152.html
which worked great on all my machines. But there were some folks
who reported that it caused them at bootup to hit this:
(XEN) domain_cras
On Tue, Jul 31, 2012 at 06:42:54AM -0400, Konrad Rzeszutek Wilk wrote:
> Which allows us to be a bit smarter in case we exhaust the reserved
> virtual space.
>
> [v1: Suggested by Ian Campbell]
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/xen/enlighten.c |
000:00:00.0: eth0: MAC: 3, PHY: 8, PBA No: E46981-005
The "Warning only" will go away if one supplies 'iommu=soft' instead
as we have a higher chance of being able to allocate large swaths of
memory.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/pci/xen-pcifront.c | 14
ri
Signed-off-by: Konrad Rzeszutek Wilk
---
include/linux/swiotlb.h |1 +
lib/swiotlb.c | 31 +++
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e872526..8d08b3e 100644
--- a/inc
: Konrad Rzeszutek Wilk
---
arch/x86/xen/pci-swiotlb-xen.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 967633a..b6a5340 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci
The original problem I mentioned in the above mentioned URL:
"if one boots a PV 64-bit guests with more than 4GB, the SWIOTLB [Xen]
gets turned on - and 64MB of precious low-memory gets used." was totally
bogus. The SWIOTLB that gets turned on is the *native* one - which does
not exhaust any low-me
With this patch we provide the functionality to initialize the
Xen-SWIOTLB late in the bootup cycle - specifically for
Xen PCI-frontend. We still will work if the user had
supplied 'iommu=soft' on the Linux command line.
CC: FUJITA Tomonori
Signed-off-by: Konrad Rzeszutek Wilk
---
If a PV guest is booted the native SWIOTLB should not be
turned on. It does not help us (we don't have any PCI devices)
and it eats 64MB of good memory. In the case of PV guests
with PCI devices we need the Xen-SWIOTLB one.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/pci-swiotlb-
> > > + /* This is superflous and shouldn't be neccessary, but you know what
> > > + * lets do it. The MODULES_VADDR -> MODULES_END should be clear of
> > > + * anything at this stage. */
> > > + xen_cleanhighmap(MODULES_VADDR, roundup(MODULES_VADDR, PUD_SIZE) - 1);
> >
> > I would stick an #ifd
> > > + for (i = 0; i < ARRAY_SIZE(addr); i++) {
> > > + unsigned j;
> > > + /* No idea about the order the addr are in, so just do them
> > > twice. */
> > > + for (j = 0; j < ARRAY_SIZE(addr); j++) {
> >
> > I don't think I understand this double loop.
>
> So with Xen t
Changelog:
Since v1: [http://lists.xen.org/archives/html/xen-devel/2012-07/msg01561.html]
- added more comments, and #ifdefs
- squashed The L4 and L4, L3, and L2 recycle patches together
- Added Acked-by's
The explanation of these patches is exactly what v1 had:
The details of this problem are
After all, this is what it is there for.
Acked-by: Jan Beulich
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/mmu.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 6ba6100..7247e5a 100644
--- a/arch/x86
ng that is within MODULES_VADDR
and up to the end of the PMD.
At this point the __ka only contains PMD entries for the start
of the kernel up to __brk.
[v1: Per Stefano's suggestion wrapped the MODULES_VADDR in debug]
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/x
As we are not using them. We end up only using the L1 pagetables
and grafting those to our page-tables.
[v1: Per Stefano's suggestion squashed two commits]
[v2: Per Stefano's suggestion simplified loop]
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/mm
B/c we do not need it. During the startup the Xen provides
us with all the memory mapped that we need to function.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/mmu.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen
out the __ka for the old P2M array.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/mmu.c | 57
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index de4b8fd..9358b75 100644
--- a/
allows us to
boot as initial domain on large machines.
So we pick option 2).
This patch only lays the groundwork in the P2M code. The patch
that modifies the MMU is called "xen/mmu: Copy and revector the P2M tree."
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/p2m.c |
On Mon, Jul 30, 2012 at 02:47:44PM -0500, Seth Jennings wrote:
> Fixes uninitialized variable warning on 'type' in frontswap_shrink().
> type is set before use by __frontswap_unuse_pages() called by
> __frontswap_shrink() called by frontswap_shrink() before use by
> try_to_unuse().
OK, applied.
>
On Fri, Jul 27, 2012 at 01:18:36PM -0500, Seth Jennings wrote:
> This patchset creates a new driver class under drivers/ for
> memory management related drivers, like zcache.
I was going back and forth with Dan whether it should be in mm/
or in drivers/mm.
>
> This driver class would be for drive
On Sun, Jul 29, 2012 at 10:54:28AM +0900, Minchan Kim wrote:
> On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org]
> > > Sent: Friday, July 27, 2012 3:00 PM
> > > Subject: Re: [PATCH 0/
On Mon, Jul 30, 2012 at 01:48:29PM -0700, Dan Magenheimer wrote:
> > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com]
> > Subject: Re: [PATCH 0/4] promote zcache from staging
> >
> > Dan,
> >
> > I started writing inline responses to each concern but that
> > was adding more confusion tha
On Tue, Jul 31, 2012 at 08:49:21AM -0700, H. Peter Anvin wrote:
> On 07/31/2012 03:42 AM, Konrad Rzeszutek Wilk wrote:
> >
> > [PATCH 3/3] x86: Let extend_brk return a NULL pointer instead of
> >
> >makes extend_brk not do BUG_ON and instead just return NULL. This
On Tue, Jul 31, 2012 at 05:41:51PM +0100, Jan Beulich wrote:
> >>> On 31.07.12 at 18:15, Konrad Rzeszutek Wilk
> >>> wrote:
> > On Tue, Jul 31, 2012 at 08:49:21AM -0700, H. Peter Anvin wrote:
> >> This means you're either abusing the brk allocato
On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote:
> > So in my head I feel that it is Ok to:
> > 1) address the concerns that zcache has before it is unstaged
> > 2) rip out the two-eng
On Tue, Jul 31, 2012 at 03:46:04PM +0100, Stefano Stabellini wrote:
> On Tue, 31 Jul 2012, Konrad Rzeszutek Wilk wrote:
> > If a PV guest is booted the native SWIOTLB should not be
> > turned on. It does not help us (we don't have any PCI devices)
> > and it eats 64MB o
On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
> On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
> wrote:
> > diffstat vs 3.5:
> > drivers/staging/ramster/Kconfig |2
> > drivers/staging/ramster/Makefile |2
> > drivers/staging/zcache/Kconfig|2
> >
> >> Signed-off-by: Andres Lagar-Cavilla
> >
> > Acked-by: Ian Campbell
> >
> > Since this is more about grant tables than netback this should probably
> > go via Konrad rather than Dave, is that OK with you Dave?
>
> If that is the case hopefully Konrad can deal with the two typos? Otherwise
v3.5 we added
batching for M2P override (Machine Frame Number -> Physical Frame Number), but
the original MFN was saved in an incorrect structure - and we would oops/restore
when restoring with the old MFN. Both of them CC the stable train. Please pull!
Konrad Rzeszutek Wilk (1):
xen/b
On Fri, Sep 21, 2012 at 10:04:18AM +0100, Oliver Chick wrote:
> Changing the type of bdev parameters to be unsigned int :1, rather than bool.
> This is more consistent with the types of other features in the block drivers.
Thanks. Put in my for-jens branch.
>
> Signed-off-by: Oliver Chick
> ---
On Fri, Sep 21, 2012 at 09:10:44AM +0100, Ian Campbell wrote:
> On Thu, 2012-09-20 at 22:24 +0100, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> > > On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > > &
On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
> On 20/09/12 12:48, Jan Beulich wrote:
> 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
On Wed, Sep 05, 2012 at 12:05:55PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sat, Sep 01, 2012 at 10:29:46PM +0200, Marcus Karlsson wrote:
> > Fix spelling in tmem.c:
> > Transcedent -> Transcendent
> >
> > Signed-off-by: Marcus Karlsson
>
> Acked-by: Konrad
On Wed, Sep 12, 2012 at 11:39:14AM +0900, Minchan Kim wrote:
> Hi all,
>
> I would like to promote zram/zsmalloc from staging tree.
> I already tried it https://lkml.org/lkml/2012/8/8/37 but I didn't get
> any response from you guys.
>
> I think zram/zsmalloc's code qulity is good and they
> are
On Wed, Sep 19, 2012 at 10:49:00AM -0700, Yinghai Lu wrote:
> Found one system one root bus hot remove get panic.
Boy, this is mangled.
Can you include the name of the system? Perhaps you can
rephrase this to say:
"On XYZ removing the root bus (through ACPI unplug) causes
a panic."
> Panic happ
On Fri, Sep 21, 2012 at 05:04:18PM +0100, David Vrabel wrote:
> The series makes all the Xen frontend drivers handle the backend
> transitioning to CLOSED without the frontend having previously seen
> the backend in the CLOSING state.
>
> Backends shouldn't do this but some do. e.g., if the host
On Fri, Sep 21, 2012 at 05:17:36PM +0100, David Vrabel wrote:
> On 21/09/12 15:27, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
> >>
> >> It's not just virtual space. blkback in pvops kernels allocates its
> >
On Fri, Sep 21, 2012 at 05:12:52PM +0100, Mel Gorman wrote:
> On Tue, Sep 04, 2012 at 04:34:46PM -0500, Seth Jennings wrote:
> > zcache is the remaining piece of code required to support in-kernel
> > memory compression. The other two features, cleancache and frontswap,
> > have been promoted to m
On Fri, Sep 21, 2012 at 04:52:47PM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O perfor
On Mon, Sep 17, 2012 at 05:29:24AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:
>
> > (I think I forgot to hit send on this on Friday, sorry. Also
> > s/xen.lists.org/lists.xen.org in the CC line…)
> I'm on a roll here…
>
> >
> > On Fri, 2012-09-14 at 15:
> *: With a PVHVM guest I get
>
> [ 261.927218] privcmd_fault: vma=88002a31dce8 7f4edc095000-7f4edc195000,
> pgoff=c8, uv=7f4edc15d000
>
> thought if I applied your patch on top of v3.6-rc6 I didn't see the
> privcmd_fault but
> I did see the guest crash.
And that is due to c571898ffc
On Fri, Sep 21, 2012 at 03:30:01PM -0400, Andres Lagar-Cavilla wrote:
> On Sep 21, 2012, at 2:52 PM, Konrad Rzeszutek Wilk wrote:
>
> > On Mon, Sep 17, 2012 at 05:29:24AM -0400, Andres Lagar-Cavilla wrote:
> >> On Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:
> >>
> > So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> > in the initial domain and the guest is crashed:
> >
> > [ 261.927218] privcmd_fault: vma=88002a31dce8
> > 7f4edc095000-7f4edc195000, pgoff=c8, uv=7f4edc15d000
>
> With this patch? Or with the mmapbatch v2? Thi
On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> > *: With a PVHVM guest I get
> >
> > [ 261.927218] privcmd_fault: vma=88002a31dce8
> > 7f4edc095000-7f4edc195000, pgoff=c8, uv=7f4edc15d000
> >
> > thought if I applied your p
>
> to allow it to use an io_tlb passed in. Note: I hadn't tested this
> on IA64 and that is something I need to do.
Done. I got my hands on a HP zx6000 and the patch series did not show
any regressions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Fri, Sep 21, 2012 at 11:27:00AM -0700, Yinghai Lu wrote:
> On Fri, Sep 21, 2012 at 9:50 AM, Konrad Rzeszutek Wilk
> wrote:
> > On Wed, Sep 19, 2012 at 10:49:00AM -0700, Yinghai Lu wrote:
> >
> > Can you include the stack trace?
>
> [ 414.997281] pci_bus
rmation
to the PV guests. When we do get to that point, then this patch will have to be
reverted.
Konrad Rzeszutek Wilk (1):
xen/boot: Disable NUMA for PV guests.
arch/x86/xen/setup.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
--
To unsubscribe from this list: sen
On Mon, Sep 24, 2012 at 10:38:48AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:
>
> > On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> *: With a PVHVM guest I get
> >>>
>
On Mon, Sep 24, 2012 at 04:27:19PM -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> %cr4 is supposed to reflect a set of features into which the operating
> system is opting in. If the BIOS or bootloader leaks bits here, this
> is not desirable. Consider a bootloader passing in %cr4.pa
el.org # only for v3.4 and v3.5
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/xen-pciback/pci_stub.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/xen/xen-pciback/pci_stub.c
b/drivers/xen/xen-pciback/pci_stub.c
index acec6fa..e5a0c13 100644
--- a/dr
One fixes that I thought I had fixed but not so. This was discovered
when trying to passthrough an PCIe network card to an PVHVM guest
and finding that it can't use MSIs. I thought I had it fixed with
git commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a
"xen/pciback: Fix proper FLR steps." but that
We call 'pci_disable_device' which sets the bus_master to zero
and it also disables the PCI_COMMAND. There is no need to
do it outside the PCI library.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/xen-pciback/pciback_ops.c |4
1 files changed, 0 insertions(+), 4
PV crowd
>
> Xen PV guests don't pass through this code path so there is no danger
> there AFAICT, so from that PoV:
>
> Acked-by: Ian Campbell
>
> FWIW it looks correct to me from the native PoV too, but you probably
> already knew that ;-)
And sanity testing co
On Tue, Sep 25, 2012 at 05:00:30PM +0200, Dor Laor wrote:
> On 09/24/2012 02:02 PM, Raghavendra K T wrote:
> >On 09/24/2012 02:12 PM, Dor Laor wrote:
> >>In order to help PLE and pvticketlock converge I thought that a small
> >>test code should be developed to test this in a predictable,
> >>determ
> Enhancements to dma-debug API are made to add new debugfs interfaces to
> report total dma errors, dma errors that are not checked, and unmap errors
> for the entire system. Please note that these are system wide counters for
> all devices in the system.
>
> The following new dma-debug interface
Hey Jens,
I've one more patch (a small change) that I was hoping you could
pull in your v3.7 branch.
The branch is:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-3.7
and has this tiny patch:
Oliver Chick (1):
xen/blkback: Change xen_vbd's flush_support and
On Fri, Oct 26, 2012 at 02:00:36PM +, Liu, Jinsong wrote:
> Updated per Jan's comments.
>
> Thanks,
> Jinsong
>
> ===
>
> >From e6d4eceba9538c6873f9c970425e65e257fd9bf0 Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong
> Date: Sat, 27 Oct 2012 05:34:50 +0800
> Subject: [PATCH 1/2] X
ere is risk of mwait #UD, if we want to
> remove mwait check as 'patch 2/2:
> Revert-pad-config-check-in-xen_check_mwait.patch' did, advantages of which is
> to enjoy deep Cx.
You are missing my point. This is what I was thinking off:
>From 5f30320b8a1c21d60a2c22e98bcf013b
On Wed, Oct 24, 2012 at 12:32:34PM +0200, Ingo Molnar wrote:
>
> * Konrad Rzeszutek Wilk wrote:
>
> > Hey Ingo, Andrew, Michel, etc.
> >
> > Was wondering if you had seen similar errors? I am building perf out-of-tree
> > (so using the O= and -C combinatio
On Wed, Oct 24, 2012 at 10:37:45AM +0100, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > diff --git a/include/xen/interface/physdev.h
> > b/include/xen/interface/physdev.h
> > index 1844d31..83050d3 100644
> > --- a/incl
On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O per
These are back-ports from the ones that Jan posted. Please
take a look - I might have missed an email about one of the patches
and I can't find it my mailbox :-(
Either way, was thinking to put these in v3.7.
arch/x86/include/asm/xen/hypercall.h | 21 +++-
drivers/xen/Makefile
lly: Some don't
require copying back anything at all, and for the rest use the
individual argument structures' sizes rather than the container's.
Reported-by: Dan Carpenter
Signed-off-by: Jan Beulich
[v2: Reduce #define/#undef usage in HYPERVISOR_physdev_op_compat().]
Signed-off-by: Ko
From: Jan Beulich
Acked-by: Ian Campbell
Reported-by: Dan Carpenter
Signed-off-by: Jan Beulich
[v1: Rebased on upstream]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/xenbus/xenbus_dev_frontend.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/xen
On Wed, Oct 24, 2012 at 02:19:16PM +0100, Ian Campbell wrote:
> This is rebased onto 0e9e3e306c7e (AKA current Linus, which now includes
> the previously prerequisite series "xen: build fixes and interface
> tweaks") and Konrad's stable/pvh.v5 branch.
>
> For convenience I've also pushed to
>
On Wed, Oct 24, 2012 at 10:40:22AM +0100, Ian Campbell wrote:
> On Tue, 2012-10-23 at 19:12 +0100, Konrad Rzeszutek Wilk wrote:
> > By making the structure exactly the same size and with the same
> > offsets on 64 and 32-bit builds we are future-proofing ourselves.
> >
>
On Mon, Oct 29, 2012 at 11:18:09AM -0700, Alexander Duyck wrote:
> On Mon, Oct 15, 2012 at 10:19 AM, Alexander Duyck
> wrote:
> > While working on 10Gb/s routing performance I found a significant amount of
> > time was being spent in the swiotlb DMA handler. Further digging found that
> > a
> > s
> > +config XEN_ACPI_PAD_STUB
> > + bool
> > + depends on XEN_DOM0 && X86_64 && ACPI
> > + default n
> > +
>
> This Kconfig is pointless, if CONFIG_XEN_ACPI_PAD_STUB = n, native pad would
> successfully registerred, and then mwait #UD (we would revert
> df88b2d96e36d9a9e325bfcd12eb45671cbb
On Wed, Oct 10, 2012 at 11:13:45PM -0700, Yinghai Lu wrote:
> On Wed, Oct 10, 2012 at 9:40 AM, Stefano Stabellini
> wrote:
> >
> > So you are missing the Xen patches entirely in this iteration of the
> > series?
>
> please check updated for-x86-mm branch.
>
> [PATCH -v4 00/15] x86: Use BRK to pr
On Mon, Oct 29, 2012 at 10:08:17AM -0400, Konrad Rzeszutek Wilk wrote:
> From: Jan Beulich
>
> While copying the argument structures in HYPERVISOR_event_channel_op()
> and HYPERVISOR_physdev_op() into the local variable is sufficiently
> safe even if the actual structure is s
On Tue, Oct 30, 2012 at 07:33:16PM +0100, Roger Pau Monné wrote:
> On 30/10/12 18:01, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 24, 2012 at 06:58:45PM +0200, Roger Pau Monne wrote:
> >> This patch implements persistent grants for the xen-blk{front,back}
> >> mechanism
On Mon, Oct 29, 2012 at 11:26:32AM +0200, Mika Westerberg wrote:
> These functions might be called from modules as well so make sure they are
> exported.
>
> Signed-off-by: Mika Westerberg
> ---
> arch/ia64/kernel/acpi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/ia64/kerne
On Mon, Oct 29, 2012 at 11:26:31AM +0200, Mika Westerberg wrote:
> From: Andy Shevchenko
>
> These functions might be called from modules as well so make sure they are
> exported. In addition we implement empty version of acpi_unregister_gsi() and
> remove the one from pci_irq.c.
>
> Signed-off-
Zhenzhong Duan wrote:
>Driver init call graph under baremetal:
>driver_init->
>msix_capability_init->
>msix_program_entries->
>msix_mask_irq->
>entry->masked = 1
>request_irq->
>__setup_irq->
>irq_startup->
>unmask_msi
t; dma_mask.
Or fix the 'xgmac'?
>
> On Mon, 30 Sep 2013, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 27, 2013 at 05:10:03PM +0100, Stefano Stabellini wrote:
> >
> > Why? I am looking at X86 and IA64 and I see:
> >
> > 79 if (!dev
On Thu, Oct 03, 2013 at 01:51:32PM +0100, Frediano Ziglio wrote:
> On Thu, 2013-10-03 at 11:04 +0100, Andrew Cooper wrote:
> > On 03/10/13 09:24, Frediano Ziglio wrote:
> > > Due to the way kernel is initialized under Xen is possible that the ring1
> > > selector used by the kernel for the boot cpu
On Wed, Oct 02, 2013 at 06:31:57PM +0100, Stefano Stabellini wrote:
> On Mon, 30 Sep 2013, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 27, 2013 at 05:10:00PM +0100, Stefano Stabellini wrote:
> > > The swiotlb code has appropriate calls to dma_mark_clean in place for
>
er, the AMD_IOMMU already depended on
> X86_64, which already guaranteed that X86_IO_APIC was enabled, so this
> dependency was anyway redundant.
>
> Signed-off-by: Thomas Petazzoni
> Reported-by: Konrad Rzeszutek Wilk
And Tested-by: Konrad Rzeszutek Wilk
Bjorn or x86 main
On Mon, Jul 08, 2013 at 08:28:24AM +0200, Michael Opdenacker wrote:
> This patch proposes to remove the XEN_PRIVILEGED_GUEST kernel
> configuration parameter defined in arch/x86/xen/Kconfig, but used
> nowhere in the makefiles and source code.
>
> This dummy parameter was added 3 years back, and i
t,
> since we re-use the same struct from the indirect operation.
>
> Signed-off-by: Roger Pau Monné
> Cc: Konrad Rzeszutek Wilk
> ---
> drivers/block/xen-blkback/blkback.c | 108 +-
> drivers/block/xen-blkback/common.h | 12 ++-
> drivers/block
Paul Bolle wrote:
>On Mon, 2013-07-08 at 22:58 +0200, Borislav Petkov wrote:
>> On Mon, Jul 08, 2013 at 01:29:40PM -0700, H. Peter Anvin wrote:
>> > What. The. Fuck.
>>
>> This is just marvellous: grub2 has a bunch of scripts in /etc/grub.d
>> which rely on the presence of kernel config files in
On Tue, Jul 09, 2013 at 08:41:12AM +0100, Jan Beulich wrote:
> >>> On 09.07.13 at 02:26, Konrad Rzeszutek Wilk
> >>> wrote:
> > Could you explain to me please why the check in the scripts is superfluous?
>
> This is not really the question - _any_ such check
On Tue, Jul 09, 2013 at 05:05:54PM +0200, Borislav Petkov wrote:
> On Tue, Jul 09, 2013 at 10:48:40AM -0400, Konrad Rzeszutek Wilk wrote:
> > Then that should be discussed on grub2 to remove said check and modify
> > the code so that it can properly work without regression.
>
On Tue, Jul 09, 2013 at 06:37:58PM +0200, Roger Pau Monné wrote:
> On 08/07/13 21:41, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jul 08, 2013 at 03:03:27PM +0200, Roger Pau Monne wrote:
> >> Right now blkfront has no way to unmap grant refs, if using persistent
> >>
On Tue, Jul 09, 2013 at 10:01:50PM +0200, Borislav Petkov wrote:
> On Tue, Jul 09, 2013 at 01:19:09PM -0400, Konrad Rzeszutek Wilk wrote:
> > My thinking is that what should be done to have some sense of history
> > is that the patch in GRUB to not rely on kernel internals should be
> So it would be nice to have at least some time to address this with upstream
> grub and the main distributions to patch their grub.
Sounds quite sensible. Michael would you be OK doing this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Jul 10, 2013 at 11:19:23AM +0200, Roger Pau Monné wrote:
> On 08/07/13 21:41, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jul 08, 2013 at 03:03:27PM +0200, Roger Pau Monne wrote:
> >> Right now blkfront has no way to unmap grant refs, if using persistent
> >>
On Wed, Jul 10, 2013 at 01:47:17PM +0300, Gleb Natapov wrote:
> On Wed, Jul 10, 2013 at 12:40:47PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 10, 2013 at 01:33:25PM +0300, Gleb Natapov wrote:
> >
> > Here's an idea, trim the damn email ;-) -- not only directed at gleb.
> >
> Good idea.
>
> > >
Gleb Natapov wrote:
>On Wed, Jul 10, 2013 at 11:03:15AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jul 10, 2013 at 01:47:17PM +0300, Gleb Natapov wrote:
>> > On Wed, Jul 10, 2013 at 12:40:47PM +0200, Peter Zijlstra wrote:
>> > > On Wed, Jul 10, 2013 at 01:33:
On Thu, Jul 11, 2013 at 08:13:58PM +0200, Paul Bolle wrote:
> On Thu, 2013-07-11 at 10:57 -0700, H. Peter Anvin wrote:
> > On 07/11/2013 03:08 AM, Paul Bolle wrote:
> > > But the Kconfig entry for XEN_PRIVILEGED_GUEST reads:
> > > # Dummy symbol since people have come to rely on the PRIVILEGED
On Tue, Sep 17, 2013 at 05:01:24PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> This message is bcc'd to each of the contacts for the trees listed below,
> so apologies if you get two copies.
>
> I have been inspired to check the ages of the trees included in
> linux-next. Below I have listed al
On Wed, Sep 04, 2013 at 09:10:50PM +0100, Zoltan Kiss wrote:
> On 03/09/13 13:42, Konrad Rzeszutek Wilk wrote:
> >Correct. The double buffering code is being run in lib/swiotlb.c not the
> >xen-swiotlb.c. Hence the question of why not move the tracing in there.
> I'v
On Wed, Sep 04, 2013 at 02:00:40PM -0700, Eric Dumazet wrote:
> On Wed, 2013-09-04 at 21:47 +0100, Zoltan Kiss wrote:
> > THIS PATCH IS NOT INTENDED TO BE UPSTREAMED, IT HAS ONLY INFORMING PURPOSES!
> >
> > I've noticed a performance regression with upstream kernels when used as
> > Dom0
> > unde
an R
> Signed-off-by: Manjunath Goudar
> Cc: David Airlie
> Cc: "Paul E. McKenney"
> Cc: David Howells
> Cc: Thomas Gleixner
> Cc: Dave Jones
> Cc: Dave Airlie
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
Reviewed-by: Konrad Rzesz
On Thu, Sep 05, 2013 at 08:39:06AM +0100, Ian Campbell wrote:
> On Wed, 2013-09-04 at 17:11 -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Sep 04, 2013 at 02:00:40PM -0700, Eric Dumazet wrote:
>
> > > Maybe you could add proper infrastructure to deal with Xen limitations.
sions before allowing OP_DISCARD).
>
> Cc: sta...@vger.kernel.org
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
Thank you for spotting that. Let me stick it on my for-jens queue.
> Signed-off-by: Vegard Nossum
> ---
> drivers/block/xen-blkback/blkback.c |3 ++-
>
We have already exported 'get_phys_to_machine' and there are
third-party drivers that depend on this other symbol. As such
lets make this balanced and also export this symbol.
Reported-by: Yuval Shaia
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/p2m.c | 1 +
1 file
301 - 400 of 2707 matches
Mail list logo
