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.3?
I
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.
Add
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, tiejun.c...@intel.com wrote:
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45, tiejun.c...@intel.com wrote:
#2 flags field in each specific device of new domctl
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 the same
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 itself
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 ian.campb...@citrix.com
---
xen/arch/arm/Rules.mk |6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/Rules.mk
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 (probably the
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;
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
`= boolean`
Default: `true`
Bits.
Andy, Any thoughts or should I investigate?
I
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 busses %s\n,
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
`= boolean`
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
`= boolean`
Default: `true`
Bits.
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
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.
They seem to
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 ian.campb...@citrix.com
Date: Wed, 19 Nov 2014 10:42:18 +
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 ian.campb...@citrix.com
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 3483179d333c47deacfc8c2eb195bf7dc4a555ff Mon
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---
From
On November 19, 2014 5:52:58 AM EST, Stefano Stabellini
stefano.stabell...@eu.citrix.com 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
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
On November 19, 2014 6:05:33 AM EST, Andrew Cooper andrew.coop...@citrix.com
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
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 ian.jack...@eu.citrix.com
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, not
Chunyan Liu writes ([PATCH 2/2 V3] fix rename: xenstore not fully updated):
libxl__domain_rename only updates /local/domain/domid/name,
/vm/uuid/name in xenstore are not updated. Add code in
libxl__domain_rename to update /vm/uuid/name too.
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
On Wed, Nov 19, 2014 at 1:12 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com 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)
On Tue, Nov 11, 2014 at 5:36 PM, Wei Liu wei.l...@citrix.com 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
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
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/domid/name,
still some places in xenstore are not updated, including:
/vm/uuid/name and
On Wed, 19 Nov 2014, Konrad Rzeszutek Wilk wrote:
On November 19, 2014 5:52:58 AM EST, Stefano Stabellini
stefano.stabell...@eu.citrix.com 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?
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 become
Hi Stefano,
if ( !list_empty(current-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;
}
Yes, exactly
I
Hi Julien,
On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall julien.gr...@linaro.org 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
On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
Hi Julien,
On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall julien.gr...@linaro.org 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:
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):
On 11/19/2014 01:30 PM, Andrii Tseglytskyi wrote:
On Wed, Nov 19, 2014 at 3:26 PM, Julien Grall julien.gr...@linaro.org wrote:
On 11/19/2014 12:40 PM, Andrii Tseglytskyi wrote:
Hi Julien,
On Wed, Nov 19, 2014 at 2:23 PM, Julien Grall julien.gr...@linaro.org
wrote:
On 11/19/2014 12:17 PM,
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
if ( !list_empty(current-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 thought i had these switched
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 follows.
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
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
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
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 ian.campb...@citrix.com
---
v2: New patch.
---
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 ian.campb...@citrix.com
Reviewed-by: Julien Grall
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
if ( !list_empty(current-arch.vgic.lr_pending) lr_all_full()
)
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.
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 think that
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
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
On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
On Wed, Nov 19, 2014 at 4:52 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
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 david.vra...@citrix.com
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
drivers/base/platform.c | 10 --
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 david.vra...@citrix.com
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
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
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
andrii.tseglyts...@globallogic.com wrote:
On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi
On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
andrii.tseglyts...@globallogic.com wrote:
On Wed, Nov 19, 2014 at 5:41 PM, Stefano Stabellini
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)
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
andrii.tseglyts...@globallogic.com wrote:
Gic dump during interrupt requesting:
(XEN) GICH_LRs (vcpu 0) mask=f
(XEN)HW_LR[0]=3a1f
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, konrad.w...@oracle.com wrote:
+static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci)
+{
+struct domain *d =
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
On Wed, Nov 19, 2014 at 6:13 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
On Wed, Nov 19, 2014 at 6:01 PM, Andrii Tseglytskyi
andrii.tseglyts...@globallogic.com wrote:
On Wed,
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, 2014, 9:56:33 PM,
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
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com 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
On Wed, Nov 19, 2014 at 7:42 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Wed, 19 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
On Wed, Nov 19, 2014 at 7:07 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
I think that's OK: it looks like that on your
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-develm=141597517132682): everything gets stuck.
Konrad, this fixes an actual bug, at least on OMAP5. It
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
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
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 QEMU 2.2 for
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-develm=141597517132682): everything
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 hypervisor
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
On 19/11/2014 18:54, Sander Eikelenboom wrote:
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
19 лист. 2014 20:32, користувач Stefano Stabellini
stefano.stabell...@eu.citrix.com написав:
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
flight 31670 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 31536
Tests which did
On 11/19/14 13:18, Stefano Stabellini wrote:
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:
On Fri, Nov 14, 2014 at 06:14:06PM +0100, Juergen Gross wrote:
On 11/14/2014 05:47 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 14, 2014 at 05:53:19AM +0100, Juergen Gross wrote:
On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
+ mfn_save = virt_to_mfn(buf);
+
+ while
Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register. This is the wrong timeout to use and, at
1000 msec., is also much too large. This patch changes the quirk code to
use a timeout that is specific to the IGD device and allows the user
control of
On Tue, Nov 11, 2014 at 06:43:45AM +0100, Juergen Gross wrote:
At start of the day the Xen hypervisor presents a contiguous mfn list
to a pv-domain. In order to support sparse memory this mfn list is
accessed via a three level p2m tree built early in the boot process.
Whenever the system needs
On Tue, Nov 11, 2014 at 06:43:38AM +0100, Juergen Gross wrote:
Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physical addresses to machine global
addresses. This p2m tree is used for construction of page table
entries, so the p2m tree walk is
On Mon, Nov 17, 2014 at 12:10:34PM +, Wei Liu wrote:
The existence check is to make sure a device is not added to a guest
multiple times.
PCI device backend path has different rules from vif, disk etc. For
example:
/local/domain/0/backend/pci/9/0/dev-1/:03:10.1
On Wed, Nov 12, 2014 at 11:40:53AM +, Stefano Stabellini wrote:
xen_dma_unmap_page and xen_dma_sync_single_for_cpu take a dma_addr_t
handle as argument, not a physical address.
Ouch. Should this also go on stable tree?
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
Before this patch, pv guest video_memkb is -1, which is an invalid value.
And it will cause the xenstore 'memory/targe' calculation wrong:
memory/target = info-target_memkb - info-video_memkb
CC-ing the maintainers.
Is this
On Wed, Nov 19, 2014 at 11:22:18AM +, Ian Campbell wrote:
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
On Wed, Nov 19, 2014 at 04:08:46PM -0500, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 18, 2014 at 03:57:08PM -0500, Zhigang Wang wrote:
Before this patch, pv guest video_memkb is -1, which is an invalid value.
And it will cause the xenstore 'memory/targe' calculation wrong:
On Wed, Nov 19, 2014 at 09:21:23PM +, Wei Liu wrote:
On Wed, Nov 19, 2014 at 04:01:54PM -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Nov 17, 2014 at 12:10:34PM +, Wei Liu wrote:
The existence check is to make sure a device is not added to a guest
multiple times.
PCI device
On Sun, Nov 16, 2014 at 10:36:28AM +0800, Simon Cao wrote:
Hi,
I was working on the work. But I was busing preparing some job interviews
in the last three months, sorry for this long delay. I will update my
progress in a few days.
OK, I put your name for this to be in Xen 4.6.
Thanks!
On Wed, Nov 19, 2014 at 08:17:35PM +0100, Sander Eikelenboom wrote:
Wednesday, November 19, 2014, 8:01:31 PM, you wrote:
On Wed, Nov 19, 2014 at 07:54:39PM +0100, Sander Eikelenboom wrote:
Wednesday, November 19, 2014, 6:31:39 PM, you wrote:
Hey,
This patch should fix the
Hey,
Attached are two patches that fix the dpci_softirq list corruption
that Sander was observing.
xen/drivers/passthrough/io.c | 55 +++-
1 file changed, 39 insertions(+), 16 deletions(-)
Konrad Rzeszutek Wilk (2):
dpci: Fix list corruption if
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
On Tue, Nov 18, 2014 at 04:49:21PM +, Stefano Stabellini wrote:
ping?
Sending something which wants my attention _To:_ me is always a good idea :)
The patch is fine in itself, but I have a niggle about the
is_device_dma_coherent() - provided this is only used in architecture
specific code,
On 11/17/2014 23:54, Jan Beulich wrote:
On 17.11.14 at 20:21, sfl...@ihonk.com wrote:
Okay, I did a bisection and was not able to correlate the above error
message with the problem I'm seeing. Not saying it's not related, but I
had plenty of successful test runs in the presence of that error.
On 19.11.14 at 02:26, tiejun.c...@intel.com wrote:
So without lookuping devices[i], how can we call func() for each sbdf as
you mentioned?
You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.
Yeah, so change this again,
From: Tian, Kevin
Sent: Wednesday, November 19, 2014 4:18 PM
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, November 12, 2014 5:57 PM
On 12.11.14 at 10:13, tiejun.c...@intel.com wrote:
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45,
95 matches
Mail list logo
