On Tue, Nov 18, 2014 at 06:24:31PM +, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [Xen-devel] delaying 4.4.2 and 4.3.4"):
> > By the way, what I should do to have commit
> > f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
> > (tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4
On Wed, 2014-11-19 at 15:12 +0800, Chunyan Liu wrote:
> While running libvirt-tck domain/102-broken-save-restore.t
> test (save domain, corrupt saved file by truncate the last 512k,
> then restore), found that restore domain failed, but domain
> related xenstore entries still exist in xenstore.
>
Hi Stefano,
Thank you for your support.
You are right - with latest change you've proposed I got a continuous
prints during platform hang:
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
(XEN) gic.c:725:d0v0 LRs full, not
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, November 12, 2014 5:57 PM
>
> >>> On 12.11.14 at 10:13, wrote:
> > On 2014/11/12 17:02, Jan Beulich wrote:
> > On 12.11.14 at 09:45, wrote:
> > #2 flags field in each specific device of new domctl would control
> > whe
On Tue, 2014-11-18 at 17:01 +, Julien Grall wrote:
> Hi Ian,
>
> On 11/18/2014 04:44 PM, Ian Campbell wrote:
> > The callers pass the end as the pfn immediately *after* the last page to be
> > mapped, therefore adding one is incorrect and causes an additional page to
> > be
> > mapped.
> >
>
At 01:29 + on 19 Nov (1416356943), Zhang, Yang Z wrote:
> Tim Deegan wrote on 2014-11-18:
> > In this case, the guest is entitled to _expect_ pagefaults on 1GB
> > mappings if CPUID claims they are not supported. That sounds like an
> > unlikely thing for the guest to be relying on, but Xen it
On Tue, 2014-11-18 at 16:59 +, Julien Grall wrote:
> Hi Ian,
>
> On 11/18/2014 04:44 PM, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell
> > ---
> > xen/arch/arm/Rules.mk |6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.m
On Tue, 2014-11-18 at 17:15 +, Julien Grall wrote:
> > +default:
> > +/* Ignore unknown PCI busses */
>
> I would add a
> printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
>
> > +ret = 0;
> > +break;
>
> continue?
Yes, that makes sense (
Hi,
On 19/11/2014 09:54, Ian Campbell wrote:
On Tue, 2014-11-18 at 16:59 +, Julien Grall wrote:
Hi Ian,
On 11/18/2014 04:44 PM, Ian Campbell wrote:
Signed-off-by: Ian Campbell
---
xen/arch/arm/Rules.mk |6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/Rules.mk
Hi Ian,
On 19/11/2014 09:56, Ian Campbell wrote:
On Tue, 2014-11-18 at 17:15 +, Julien Grall wrote:
+default:
+/* Ignore unknown PCI busses */
I would add a
printk("Ignoring PCI busses %s\n", dt_node_full_name(dev));
+ret = 0;
+break;
contin
On Tue, 2014-11-18 at 14:50 -0500, Timothy Wood wrote:
> On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell
> wrote:
>
> On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
> > Hi,
> >
> > I am curious if Xen currently supports sharing hugepages
> between
>
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
bunch of random sha id's in it, where the 4.4-testing version does not.
They seem to have replaced the various
`= `
Default: `true`
Bits.
Andy, Any thoughts or should I investigate?
I don't se
On Wed, 2014-11-19 at 10:06 +, Julien Grall wrote:
> Hi Ian,
>
> On 19/11/2014 09:56, Ian Campbell wrote:
> > On Tue, 2014-11-18 at 17:15 +, Julien Grall wrote:
> >>> +default:
> >>> +/* Ignore unknown PCI busses */
> >>
> >> I would add a
> >> printk("Ignoring PCI buss
On Wed, 2014-11-19 at 10:12 +, Ian Campbell wrote:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> bunch of random sha id's in it, where the 4.4-testing version does not.
>
> They seem to have replaced the various
> `= `
>
> Default: `true`
>
On 19/11/14 10:12, Ian Campbell wrote:
> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> bunch of random sha id's in it, where the 4.4-testing version does not.
>
> They seem to have replaced the various
> `= `
>
> Default: `true`
>
> Bits.
On Wed, 2014-11-19 at 10:24 +, Andrew Cooper wrote:
> On 19/11/14 10:12, Ian Campbell wrote:
> > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> > bunch of random sha id's in it, where the 4.4-testing version does not.
> >
> > They seem to have replaced the various
> >
On 19/11/2014 10:18, Ian Campbell wrote:
On Wed, 2014-11-19 at 10:06 +, Julien Grall wrote:
Hi Ian,
On 19/11/2014 09:56, Ian Campbell wrote:
On Tue, 2014-11-18 at 17:15 +, Julien Grall wrote:
+default:
+/* Ignore unknown PCI busses */
I would add a
printk("Igno
On 19/11/14 10:30, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:24 +, Andrew Cooper wrote:
>> On 19/11/14 10:12, Ian Campbell wrote:
>>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
>>> bunch of random sha id's in it, where the 4.4-testing version does not.
>>>
>>> Th
On Wed, 2014-11-19 at 10:37 +, Andrew Cooper wrote:
> On 19/11/14 10:30, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 10:24 +, Andrew Cooper wrote:
> >> On 19/11/14 10:12, Ian Campbell wrote:
> >>> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html has a
> >>> bunch of random
On Wed, 2014-11-19 at 10:38 +, Ian Campbell wrote:
> I've not been able to find a workaround...
This works for me...
8<---
>From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
From: Ian Campbell
Date: Wed, 19 Nov 2014 10:42:18 +
Subject: [PATCH] docs: work
On 19/11/14 10:46, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:38 +, Ian Campbell wrote:
>> I've not been able to find a workaround...
> This works for me...
>
> 8<---
>
> From 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon Sep 17 00:00:00 2001
> From: Ian Campbell
> Date: Wed, 19
ping?
On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> Konrad,
> I think we should have this fix in Xen 4.5. Should I go ahead and
> backport it?
>
> On Mon, 17 Nov 2014, Don Slutz wrote:
> > The other callers to blk_set_enable_write_cache() in this file
> > already check for s->blk == NULL.
> >
On Wed, 2014-11-19 at 10:52 +, Andrew Cooper wrote:
> On 19/11/14 10:46, Ian Campbell wrote:
> > On Wed, 2014-11-19 at 10:38 +, Ian Campbell wrote:
> >> I've not been able to find a workaround...
> > This works for me...
> >
> > 8<---
> >
> > From 3483179d333c47deacfc8c2eb195bf7
On 19/11/14 11:04, Ian Campbell wrote:
> On Wed, 2014-11-19 at 10:52 +, Andrew Cooper wrote:
>> On 19/11/14 10:46, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 10:38 +, Ian Campbell wrote:
I've not been able to find a workaround...
>>> This works for me...
>>>
>>> 8<---
>>
On November 19, 2014 5:52:58 AM EST, Stefano Stabellini
wrote:
>ping?
>
>On Tue, 18 Nov 2014, Stefano Stabellini wrote:
>> Konrad,
>> I think we should have this fix in Xen 4.5. Should I go ahead and
>> backport it?
Go for it. Release-Acked-by: Konrad Rzeszutek Wilk (konrad.w...@oracle.com)
>>
flight 31668 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
Tests which did not
On November 19, 2014 6:05:33 AM EST, Andrew Cooper
wrote:
>On 19/11/14 11:04, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 10:52 +, Andrew Cooper wrote:
>>> On 19/11/14 10:46, Ian Campbell wrote:
On Wed, 2014-11-19 at 10:38 +, Ian Campbell wrote:
> I've not been able to find a wo
Chunyan Liu writes ("[PATCH 1/2 V3] remove domain field in xenstore backend
dir"):
> Remove the unusual 'domain' field under backend directory. The
> affected are backend/console, backend/vfb, backend/vkbd.
Thanks.
Acked-by: Ian Jackson
___
Xen-devel
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> Thank you for your support.
>
> You are right - with latest change you've proposed I got a continuous
> prints during platform hang:
>
> (XEN) gic.c:725:d0v0 LRs full, not injecting irq=2 into d0v0
> (XEN) gic.c:725:d0v0 LRs full,
Chunyan Liu writes ("[PATCH 2/2 V3] fix rename: xenstore not fully updated"):
> libxl__domain_rename only updates /local/domain//name,
> /vm//name in xenstore are not updated. Add code in
> libxl__domain_rename to update /vm//name too.
Acked-by: Ian Jackson
__
Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
> On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>>
>> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
>>
>> >>
>> >> Uhmm i thought i had these switched off (due to problems earlier and then
>> >> forgot
>> >> abou
On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> Thank you for your support.
>>
>> You are right - with latest change you've proposed I got a continuous
>> prints during platform hang:
>>
>> (XEN) gic.c:725:d0v0 LRs fu
In both of these cases, markdown was interpreting the text as regular text,
and reflowing it as a regular paragraph, leading to a single line as output.
Reformat them as code blocks inside blockquote blocks, which causes them to
take their precise whitespace layout.
Signed-off-by: Andrew Cooper
C
On Tue, Nov 11, 2014 at 5:36 PM, Wei Liu wrote:
> Third stage:
>
>Basic PoD Ballooning Mem_relocation
> PV/PVH Y na Y na
> HVM Y YY X
>
> NUMA-aware PoD?
Hmm, that will certainly be interesting. :-)
The point of PoD is t
On Wed, 2014-11-19 at 11:17 +, Andrew Cooper wrote:
> In both of these cases, markdown was interpreting the text as regular text,
> and reflowing it as a regular paragraph, leading to a single line as output.
> Reformat them as code blocks inside blockquote blocks, which causes them to
> take t
Hi Konrad, I have another release ack request:
Chunyan Liu writes ("[PATCH 0/2 V3] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain//name,
> still some places in xenstore are not updated, including:
> /vm//name and /local/domain/0/backend///.../d
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> Thank you for your support.
> >>
> >> You are right - with latest change you've proposed I got a continuous
>
On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
>> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> Thank you for your support.
>> >>
>> >> Yo
On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On November 19, 2014 5:52:58 AM EST, Stefano Stabellini
> wrote:
> >ping?
> >
> >On Tue, 18 Nov 2014, Stefano Stabellini wrote:
> >> Konrad,
> >> I think we should have this fix in Xen 4.5. Should I go ahead and
> >> backport it?
>
> Go for it.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 1:42 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
> >> wrote:
> >> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> >> Hi St
On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> So it looks like there is not actually anything wrong, is just that you
> have too much inflight irqs? It should cause problems because in that
> case GICH_HCR_UIE should be set and you should get a maintenance
> interrupt when LRs beco
On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> > So it looks like there is not actually anything wrong, is just that you
> > have too much inflight irqs? It should cause problems because in that
> > case GICH_HCR_UIE should be set and you s
On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
> On Wed, 19 Nov 2014, Ian Campbell wrote:
>> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
>>> So it looks like there is not actually anything wrong, is just that you
>>> have too much inflight irqs? It should cause problems because
Hi Stefano,
> > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> > -GICH[GICH_HCR] |= GICH_HCR_UIE;
> > +GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > else
> > -GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> > +GICH[GICH_HCR] &= ~GICH_HCR_NPIE;
> >
> > }
>
> Ye
Hi Julien,
On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall wrote:
> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>> On Wed, 19 Nov 2014, Ian Campbell wrote:
>>> On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
So it looks like there is not actually anything wrong, is just that
On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
> Hi Julien,
>
> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall wrote:
>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>> On Wed, 19 Nov 2014, Ian Campbell wrote:
On Wed, 2014-11-19 at 11:42 +, Stefano Stabellini wrote:
> So it l
On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall wrote:
> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>> Hi Julien,
>>
>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall
>> wrote:
>>> On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
On Wed, 19 Nov 2014, Ian Campbell wrote:
> On Wed, 2
Il 14/11/2014 12:25, Fabio Fantoni ha scritto:
dom0 xen-unstable from staging git with "x86/hvm: Extend HVM cpuid
leaf with vcpu id" and "x86/hvm: Add per-vcpu evtchn upcalls" patches,
and qemu 2.2 from spice git (spice/next commit
e779fa0a715530311e6f59fc8adb0f6eca914a89):
https://github.com/
On 11/19/2014 01:30 PM, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall wrote:
>> On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
>>> Hi Julien,
>>>
>>> On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall
>>> wrote:
On 11/19/2014 12:17 PM, Stefano Stabellini wrote:
>>>
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> > > -GICH[GICH_HCR] |= GICH_HCR_UIE;
> > > +GICH[GICH_HCR] |= GICH_HCR_NPIE;
> > > else
> > > -GICH[GICH_HCR] &= ~GICH_HCR_UIE;
> >
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. Where as in pc_init1 is is
returning true.
On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>
> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>
> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
> >>
> >> Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
> >>
> >> >>
> >> >> Uhmm i though
Hello Jan and Konrad,
Tuesday, November 18, 2014, 1:49:13 PM, you wrote:
>>
>> I've just checked this with lspci. I see that the IO is being enabled.
> Memory you mean.
Yes. Sorry.
>> Any other idea on why I might be reading back 0xff for all PCI
>> memory area reads? The lspci output
Hi Stefano,
On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
>> > > -GICH[GICH_HCR] |= GICH_HCR_UIE;
>> > > +GICH[GICH_HCR] |= G
Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.
This results in no change for Mustang.
Signed-off-by: Ian Campbell
-
These patches:
* fix up an off by one bug in the xgene mapping of additional PCI
bus resources, which would cause an additional extra page to be
mapped
* correct the size of the mapped regions to match the docs
* adds support for the other 4 PCI buses on the chip,
The callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.
At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is ju
Signed-off-by: Ian Campbell
---
v2: Remove pointless/unused baud rate setting.
A bunch of other entries have these, but cleaning them up is out of scope here
I think.
---
xen/arch/arm/Rules.mk |5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules
EARLY_PRINTK_BAUD doesn't do anything unless EARLY_PRINTK_INIT_UART is set.
Furthermore only the pl011 driver implements the init routine at all, so the
entries which use 8250 and specified a BAUD were doubly wrong.
Signed-off-by: Ian Campbell
---
v2: New patch.
---
xen/arch/arm/Rules.mk |7
The region assigned to PCIE0, according to the docs, is 0x0e0 to
0x100. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/platforms
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> Hi Stefano,
> >>
> >> > > if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full()
> >> > > )
> >> > > -
flight 31669 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31669/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a
test-amd64-amd64-rumpuserxen-amd64
Il 19/11/2014 15:56, Don Slutz ha scritto:
I think I know what is happening here. But you are pointing at the
wrong change.
commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
Is what I am guessing at this time is the issue. I think that
xen_enabled() is
returning false in pc_machine_initfn. W
On Wed, 19 Nov 2014, Fabio Fantoni wrote:
> Il 19/11/2014 15:56, Don Slutz ha scritto:
> > I think I know what is happening here. But you are pointing at the wrong
> > change.
> >
> > commit 9b23cfb76b3a5e9eb5cc899eaf2f46bc46d33ba4
> >
> > Is what I am guessing at this time is the issue. I thin
On systems where DMA addresses and physical addresses are not 1:1
(such as Xen PV guests), the generic dma_get_required_mask() will not
return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow t
On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to
On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>> wrote:
>> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> >> Hi Stefano,
>> >>
>> >> > > if ( !list_empt
A generic dma_get_required_mask() is useful even for architectures (such
as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.
Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
drivers/base/platform.c | 10 --
include/linux/dma-mapping.h |1 +
2 files changed, 9 inser
Use dma_ops->get_required_mask() if provided, defaulting to
dma_get_requried_mask_from_max_pfn().
This is needed on systems (such as Xen PV guests) where the DMA
address and the physical address are not equal.
ARCH_HAS_DMA_GET_REQUIRED_MASK is defined in asm/device.h instead of
asm/dma-mapping.h
Signed-off-by: David Vrabel
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/include/asm/machvec.h |2 +-
arch/ia64/include/asm/machvec_init.h |1 -
arch/ia64/pci/pci.c | 20
3 files changed, 1 insertion(+), 22 deleti
On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
wrote:
> On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> wrote:
>> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>>> Hi Stefano,
>>>
>>> On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
>>> wrote:
>>> > On Wed, 19 Nov 2014, Andrii Tse
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> wrote:
> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> > wrote:
> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >>> Hi Stefano,
> >>>
> >>> On Wed, Nov 19, 2014 at 4:52 PM, Stefa
On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
>> wrote:
>> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
>> > wrote:
>> >> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>
Gic dump during interrupt requesting:
(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)HW_LR[0]=3a1f
(XEN)HW_LR[1]=9a015856
(XEN)HW_LR[2]=1a1b
(XEN)HW_LR[3]=9a00e439
(XEN) Inflight irq=31 lr=0
(XEN) Inflight irq=86 lr=1
(XEN) Inflight irq=27 lr=2
(XEN) Inflight irq=57 lr=3
(XEN) Infligh
BTW - shouldn't this flag GICH_LR_MAINTENANCE_IRQ be set after
maintenance interrupt requesting ?
On Wed, Nov 19, 2014 at 6:32 PM, Andrii Tseglytskyi
wrote:
> Gic dump during interrupt requesting:
>
> (XEN) GICH_LRs (vcpu 0) mask=f
> (XEN)HW_LR[0]=3a1f
> (XEN)HW_LR[1]=9a015856
> (XEN)
On Fri, Nov 14, 2014 at 11:11:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 14, 2014 at 03:13:42PM +, Jan Beulich wrote:
> > >>> On 12.11.14 at 03:23, wrote:
> > > +static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
> > > +{
> > > +struct domain *d = pirq_dpci->dom
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
> wrote:
> > On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> >> On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
> >> wrote:
> >> > On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
> >> >
No, that's for requesting a maintenance interrupt for a specific irq
when it is EOI'ed by the guest.
In our case we are requesting maintenance interrupts via UIE: a single
global maintenance interrupt when most LRs become free.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> BTW - shouldn't this
I got this strange log:
(XEN) received maintenance interrupt irq=1023
And platform does not hang due to this:
+hcr = GICH[GICH_HCR];
+if ( hcr & GICH_HCR_UIE )
+{
+GICH[GICH_HCR] &= ~GICH_HCR_UIE;
+uie_on = 1;
+}
On Wed, Nov 19, 2014 at 6:50 PM, Stefano Stabellini
Does number 1023 mean that maintenance interrupt is global?
On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
wrote:
> I got this strange log:
>
> (XEN) received maintenance interrupt irq=1023
>
> And platform does not hang due to this:
> +hcr = GICH[GICH_HCR];
> +if ( hcr & GICH_HCR_UI
I think that's OK: it looks like that on your board for some reasons
when UIE is set you get irq 1023 (spurious interrupt) instead of your
normal maintenance interrupt.
But everything should work anyway without issues.
This is the same patch as before but on top of the lastest xen-unstable
tree.
Wednesday, November 19, 2014, 4:04:59 PM, you wrote:
> On Wed, Nov 19, 2014 at 12:16:44PM +0100, Sander Eikelenboom wrote:
>>
>> Wednesday, November 19, 2014, 2:55:41 AM, you wrote:
>>
>> > On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
>> >>
>> >> Tuesday, November 18, 20
If we pass in INTx type devices to a guest on an over-subscribed
machine - and in an over-worked guest - we can cause the
pirq_dpci->softirq_list to become corrupted.
The reason for this is that the 'pt_irq_guest_eoi' ends up
setting the 'state' to zero value. However the 'state' value
(STATE_SCHE
Hey,
This patch should fix the issue that Sander had seen. The full details
are in the patch itself. Sander, if you could - please test origin/staging
with this patch to make sure it does fix the issue.
xen/drivers/passthrough/io.c | 27 +--
Konrad Rzeszutek Wilk (1):
On Wed, 19 Nov 2014, David Vrabel wrote:
> Signed-off-by: David Vrabel
> Cc: Tony Luck
> Cc: Fenghua Yu
> Cc: linux-i...@vger.kernel.org
Reviewed-by: Stefano Stabellini
> arch/ia64/include/asm/machvec.h |2 +-
> arch/ia64/include/asm/machvec_init.h |1 -
> arch/ia64/pci/pci.c
Hi Stefano,
On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
wrote:
> I think that's OK: it looks like that on your board for some reasons
> when UIE is set you get irq 1023 (spurious interrupt) instead of your
> normal maintenance interrupt.
OK, but I think this should be investigated too. W
No, it just means "spurious interrupt".
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Does number 1023 mean that maintenance interrupt is global?
>
> On Wed, Nov 19, 2014 at 7:03 PM, Andrii Tseglytskyi
> wrote:
> > I got this strange log:
> >
> > (XEN) received maintenance interrupt irq=1023
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
>
> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
> wrote:
> > I think that's OK: it looks like that on your board for some reasons
> > when UIE is set you get irq 1023 (spurious interrupt) instead of your
> > normal maintenance i
On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
wrote:
> On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
>> wrote:
>> > I think that's OK: it looks like that on your board for some reasons
>> > when UIE is set you get irq
I have posted the patch:
Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
for xenfv machine
Date: Wed, 19 Nov 2014 12:30:57 -0500
Message-ID: <1416418257-10166-1-git-send-email-dsl...@verizon.com>
Which fixes QEMU 2.2 for xenfv. However if you configure xen_platfor
UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
Konrad, this fixes an actual bug, at least on OMAP5. It shoul
On Wed, 19 Nov 2014, David Vrabel wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
>
> Some device drivers (such as mptsas, mpt2sas) use
> dm
The only ambiguity left - maintenance interrupt handler is not called.
It was requested for specific IRQ number, retrieved from device tree.
But when we trigger GICH_HCR_UIE - we got maintenance interrupt for
spurious number 1023.
Regards,
Andrii
On Wed, Nov 19, 2014 at 7:47 PM, Andrii Tseglytsky
That's right, the maintenance interrupt handler is not called, but it
doesn't do anything so we are fine. The important thing is that an
interrupt is sent and git_clear_lrs gets called on hypervisor entry.
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
> The only ambiguity left - maintenance inter
On Wed, 19 Nov 2014, Don Slutz wrote:
> I have posted the patch:
>
> Subject: [BUGFIX][PATCH for 2.2 1/1] hw/i386/pc_piix.c: Also pass vmport=off
> for xenfv machine
> Date: Wed, 19 Nov 2014 12:30:57 -0500
> Message-ID: <1416418257-10166-1-git-send-email-dsl...@verizon.com>
>
>
> Which fixes QEM
On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> That's right, the maintenance interrupt handler is not called, but it
> doesn't do anything so we are fine. The important thing is that an
> interrupt is sent and git_clear_lrs gets called on hypervisor entry.
It would be worth to write down this
On Wed, Nov 19, 2014 at 05:44:49PM +, Stefano Stabellini wrote:
> UIE being set can cause maintenance interrupts to occur when Xen writes
> to one or more LR registers. The effect is a busy loop around the
> interrupt handler in Xen
> (http://marc.info/?l=xen-devel&m=141597517132682): everythin
On Wed, 19 Nov 2014, Julien Grall wrote:
> On 11/19/2014 06:14 PM, Stefano Stabellini wrote:
> > That's right, the maintenance interrupt handler is not called, but it
> > doesn't do anything so we are fine. The important thing is that an
> > interrupt is sent and git_clear_lrs gets called on hyperv
On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 19, 2014 at 05:44:49PM +, Stefano Stabellini wrote:
> > UIE being set can cause maintenance interrupts to occur when Xen writes
> > to one or more LR registers. The effect is a busy loop around the
> > interrupt handler in Xen
> >
Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
> Hey,
> This patch should fix the issue that Sander had seen. The full details
> are in the patch itself. Sander, if you could - please test origin/staging
> with this patch to make sure it does fix the issue.
> xen/drivers/passthrough/io.
1 - 100 of 139 matches
Mail list logo
