This uses the API version of the proposed vscsi support in libxl (v4):
http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg01949.html
Is there anything else that needs to be done in libvirt? Right now libvirt scsi
support is very simple minded, no support at all to describe host devices
Upcoming changes for vscsi will use libxlutil.so to prepare the
configuration for libxl. The helpers needs a xlu struct for logging.
Provide one and reuse the existing output as log target.
Signed-off-by: Olaf Hering
Cc: Jim Fehlig
---
src/libxl/libxl_conf.c | 6 ++
src/libxl/libxl_conf.h |
On Mon, 2015-04-27 at 09:43 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> We are burrying direct access to MTRR code support on
> x86 in order to take advantage of PAT. In the future we
> also want to make the default behaviour of ioremap_nocache()
> to use strong UC, use of mtr
Hi, everyone
The xen we used is 4.0.1, but xenalyze �Cversion tells me “xenalyze -
Open-source xen-unstable (3.4)” . can I use it? Is the latest version of
xenalyze available?
Thanks a lot
.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Tue, Apr 28, Wei Liu wrote:
> On Mon, Apr 27, 2015 at 01:22:14PM +, Olaf Hering wrote:
> > It causes a crash, dump data and return early
> This doesn't look right. You skip all things below.
Yes, to avoid the crash when booted with "tbuf_size=-1". When I noticed
that I did not have the en
On Mon, Apr 27, David Vrabel wrote:
> On 27/04/15 14:22, Olaf Hering wrote:
> > This merges xenalyze.hg, changeset 150:24308507be1d into tools/misc
> > to have the tool and public/trace.h in one place.
>
> Would this not be better in tools/xentrace/xenalyze ?
Yes, I forgot that tools/xentrace/ e
On Mon, Apr 27, 2015 at 01:22:10PM +, Olaf Hering wrote:
> This merges xenalyze.hg, changeset 150:24308507be1d into tools/misc
> to have the tool and public/trace.h in one place.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
> -
On Mon, Apr 27, 2015 at 01:22:14PM +, Olaf Hering wrote:
> It causes a crash, dump data and return early
>
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
> ---
> tools/misc/xenalyze.c | 4
> 1 file changed, 4 insertions(+)
>
From: Elena Ufimtseva
Add Xen command line option rmrr to specify RMRR
regions for devices that are not defined in ACPI thus
causing IO Page Fault while booting dom0 in PVH mode.
These additional regions will be
From: Elena Ufimtseva
In preparation for auxiliary RMRR data provided on Xen
command line, make RMRR adding a separate function.
No functional changes.
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Kevin Tian
Signed-off-by: Elena Ufimtseva
---
xen/drivers/passthrough/vtd/dmar.c | 123 ++
From: Elena Ufimtseva
On some platforms RMRR regions may be not specified
in ACPI and thus will not be mapped 1:1 in dom0. This
causes IO Page Faults and prevents dom0 from booting
in PVH mode.
New Xen command line option rmrr allows to specify
such devices and memory regions. These regions are a
>>> "Wu, Feng" 04/24/15 7:50 PM >>>
>Ping..
I'm confused - I said "it makes little sense to wait", i.e. go ahead posting v2
without
waiting for me.
Jan
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, April 13, 2015 5:13 AM
> To: Wu, Feng
> Cc: Tian,
flight 52622 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 36755
build-i386-libvir
On 04/27/2015 04:15 PM, Boris Ostrovsky wrote:
On 04/27/2015 11:40 AM, Sander Eikelenboom wrote:
Monday, April 27, 2015, 4:55:06 PM, you wrote:
Hi David / Konrad,
Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in
early boot.
Xen console was still reponsive so i dumped some i
flight 52624 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 50391
build-i386-pvops
On 04/27/2015 11:40 AM, Sander Eikelenboom wrote:
Monday, April 27, 2015, 4:55:06 PM, you wrote:
Hi David / Konrad,
Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot.
Xen console was still reponsive so i dumped some info with the debug keys.
Serial log is attached.
flight 52620 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 36512
build-i386-pvops
flight 52623 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-build fail REGR. vs. 50408
build-i386-rumpus
Currently, the GICv3 drivers is only able to send an SGI when the cpumask
is provided. Although with the modes SGI_TARGET_OTHERS and SGI_TARGET_SELF,
no cpumask is provided. Any usage of those modes will crash the hypersivor.
Move the rename gicv3_send_sgi to gicv3_send_sgi_list and implement the
On Wed, Apr 22, 2015 at 12:26 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> We are burrying direct access to MTRR code support on
> x86 in order to take advantage of PAT. In the future we
> also want to make the default behaviour of ioremap_nocache()
> to use strong UC, use of mtrr
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On Sat, Apr 25, 2015 at 07:12:05AM -0400, Andy Walls wrote:
> Hi Luis,
>
> Sorry for the late reply.
>
> Thank you for the patch! See my comments below:
>
> On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > We are burrying direct access to MTRR c
Hi Stefano,
On 27/04/15 16:36, Stefano Stabellini wrote:
> On Mon, 27 Apr 2015, Julien Grall wrote:
>> The commit 569fb6c "xen/arm: Data abort exception (R/W) mem_access
>> events" makes apply_p2m_changes to call hypercall_preempt_check for any
>> operation rather than for relinquish.
>>
>> The fu
On Mon, Apr 27, 2015 at 6:13 PM, Julien Grall
wrote:
> Hi Tamas,
>
> On 27/04/15 16:40, Tamas K Lengyel wrote:
> > IMHO we should check if op==RELINQUISH || op==MEMACCESS before
> > calling hypercall_preempt_check. That was a change I made - previously
> > it was only called if the op was RELINQU
Hi Tamas,
On 27/04/15 16:40, Tamas K Lengyel wrote:
> IMHO we should check if op==RELINQUISH || op==MEMACCESS before
> calling hypercall_preempt_check. That was a change I made - previously
> it was only called if the op was RELINQUISH and not the other way around.
I though about it but it make t
Hi David / Konrad,
Here the other problem i found, which is introduced somewhere in the
4.1 mergewindow:
on 4.1.0-rc1 (with the one revert to get things booting) i get this in
the PV Guest console:
[0.517392] crc32c_combine: 8373 self tests passed
[0.517608] pci_hotplug: PCI Hot Plug PC
Hi Konrad,
On 24/04/15 21:47, Konrad Rzeszutek Wilk wrote:
> To help on certain platforms to run.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> xen/arch/x86/efi/efi-boot.h | 10 --
> xen/common/efi/boot.c | 28 +++-
> xen/common/efi/efi.h| 2 +-
IMHO we should check if op==RELINQUISH || op==MEMACCESS before calling
hypercall_preempt_check.
That was a change I made - previously it was only called if the op was
RELINQUISH
and not the other way around.
Tamas
On Mon, Apr 27, 2015 at 4:39 PM, Julien Grall
wrote:
> The commit 569fb6c "xen/ar
Monday, April 27, 2015, 4:55:06 PM, you wrote:
> Hi David / Konrad,
> Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early
> boot.
> Xen console was still reponsive so i dumped some info with the debug keys.
> Serial log is attached.
> The kernel boots fine on baremetal a
On Mon, 27 Apr 2015, Julien Grall wrote:
> The commit 569fb6c "xen/arm: Data abort exception (R/W) mem_access
> events" makes apply_p2m_changes to call hypercall_preempt_check for any
> operation rather than for relinquish.
>
> The function hypercall_preempt_check call local_events_need_delivery
>
__p2m_lookup should be called with the p2m lock taken. Add an ASSERT in
order to catch wrong caller in debug build.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 8dfee24..65efa94 100644
--- a/x
dom)), from a PV guest console it
hangs at:
[0.00] PAT configuration [0-7]: WB WT UC- UC WC WP UC UC
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.1.
Hi David / Konrad,
Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot.
Xen console was still reponsive so i dumped some info with the debug keys.
Serial log is attached.
The kernel boots fine on baremetal and my previous test kernel that was pulled
and compiled on 20
The commit 569fb6c "xen/arm: Data abort exception (R/W) mem_access
events" makes apply_p2m_changes to call hypercall_preempt_check for any
operation rather than for relinquish.
The function hypercall_preempt_check call local_events_need_delivery
which rely on the current VCPU is not an idle VCPU.
On 04/27/2015 06:33 AM, David Vrabel wrote:
On 08/04/15 19:53, Boris Ostrovsky wrote:
Commit 77e32c89a711 ("clockevents: Manage device's state separately for
the core") decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it won't be calling its
set
On 27/04/15 14:22, Olaf Hering wrote:
> This merges xenalyze.hg, changeset 150:24308507be1d into tools/misc
> to have the tool and public/trace.h in one place.
Would this not be better in tools/xentrace/xenalyze ?
David
___
Xen-devel mailing list
Xen-
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/misc/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 51a2d1d..58e8456 100644
--- a/tools/misc/xenalyze.c
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/misc/xenalyze.c | 73 ++-
1 file changed, 66 insertions(+), 7 deletions(-)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index
It causes a crash, dump data and return early
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/misc/xenalyze.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 0566d00..67b44b5
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/misc/xenalyze.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 58e8456..0566d00 100644
--- a/tools/misc/xenalyze.c
+++ b/tools/mi
Result of "sed -i 's@[[:blank:]]\+$@@' tools/misc/xenalyze.c"
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/misc/xenalyze.c | 350 +-
1 file changed, 175 insertions(+), 175 deletions(-)
Having xenalyze in the source tree makes it much easier to keep private
debug code in hypervisor and xenalyze in sync. It helped alot while
debugging the root cause for commit 607e8494c42397fb249191904066cace6ac9a880.
Olaf
Olaf Hering (7):
xenalyze: add to tools/misc
xenalyze: print newline a
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/misc/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 5f0757b..51a2d1d 100644
--- a/tools/misc/xenalyze.c
On 08/04/15 19:53, Boris Ostrovsky wrote:
> Commit 77e32c89a711 ("clockevents: Manage device's state separately for
> the core") decouples clockevent device's modes from states. With this
> change when a Xen guest tries to resume, it won't be calling its
> set_mode op which needs to be done on each
Hi Jan,
On 27/04/2015 08:02, Jan Beulich wrote:
Julien Grall 04/25/15 10:37 PM >>>
On 21/04/2015 20:13, Jan Beulich wrote:
For this specific one - is there a reasonable use case? Other than
for host PFN, we have control over guest ones, and I'm not sure
managing a guest with GPFNs extending p
On Thu, 2015-04-23 at 00:34 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Wednesday, April 22, 2015 8:50 PM
> > To: Ian Campbell
> > Cc: Pang, LongtaoX; xen-devel@lists.xen.org; wei.l...@citrix.com; Hu, Robert
> > Subject:
From: "Edgar E. Iglesias"
Because we share the p2m tables between SMMU and CPUs,
we need to make sure the SMMU is configured to use the
same S2 input-size as the CPU.
Signed-off-by: Edgar E. Iglesias
---
xen/drivers/passthrough/arm/smmu.c | 17 +++--
1 file changed, 15 insertions(+
From: "Edgar E. Iglesias"
Save and expose the p2m IPA address size to arch specific code.
This is primarily needed to setup SMMUs as these share p2m
tables with guest CPUs.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/p2m.c| 7 ++-
xen/include/asm-arm/p2m.h | 3 +++
2 files ch
From: "Edgar E. Iglesias"
Hi,
This is a first try at fixing the issue I'm seeing on ZynqMP with
missmatched setup of the SMMU and the shared page-tables with p2m.
I've only handled the case of having an SMMU that supports larger
s2 input-sizes than what p2m wants to use.
To support the case we
Hi Julien,
On 25 April 2015 at 21:48, Julien Grall wrote:
> Hi Pranav,
>
> On 24/04/2015 15:46, Pranavkumar Sawargaonkar wrote:
>>
>> In old X-Gene Storm firmware and DT, secure mode addresses have been
>> mentioned in GICv2 node. In this case maintenance interrupt is used
>> instead of EOI HW me
>>> Julien Grall 04/25/15 10:37 PM >>>
>On 21/04/2015 20:13, Jan Beulich wrote:
>> For this specific one - is there a reasonable use case? Other than
>> for host PFN, we have control over guest ones, and I'm not sure
>> managing a guest with GPFNs extending past 4 billion can be
>> expected to wor
51 matches
Mail list logo
