flight 58739 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866
build-amd64-rumpuserx
flight 58722 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58722/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 584
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, June 12, 2015 11:27 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: RE: [OSSTEST Nested PATCH v11 6/7] Compose the main
flight 58723 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58723/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58714
test-amd64-i386-xl-qemuu-win7-amd64 1
On 2015/6/18 16:05, Jan Beulich wrote:
On 18.06.15 at 09:01, wrote:
On 2015/6/18 14:29, Jan Beulich wrote:
On 18.06.15 at 08:17, wrote:
On 2015/6/17 17:24, Jan Beulich wrote:
On 17.06.15 at 11:18, wrote:
On 2015/6/17 17:02, Jan Beulich wrote:
On 17.06.15 at 10:26, wrote:
Something hits
On 2015/6/18 18:07, Tim Deegan wrote:
At 14:13 +0800 on 12 Jun (1434118407), Chen, Tiejun wrote:
could you explain why existing guest_physmap_remove_page can't
serve the purpose so you need invent a new identity mapping
specific one? For unmapping suppose it should be common regardless
of whethe
flight 58721 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58721/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 58708
test-amd64-i386-libvirt
flight 58720 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
On 06/18/2015 08:30 AM, Guenter Roeck wrote:
> On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote:
> [ ... ]
>> What happened to this series? I want to add shutdown support to my
>> platform and I need to write a register on the PMIC in one driver to
>> configure it for shutdown instead o
On 06/18/15 13:05, Andrew Cooper wrote:
> On 18/06/15 16:55, Don Slutz wrote:
>> This allows reading and writing of variables in the hypervisor.
>>
>> for example (read case -- default 4 bytes):
>>
>> xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level
>> opt_hvm_debug_level @ 0x82d0802856
On 06/18/15 12:59, Andrew Cooper wrote:
> On 18/06/15 16:55, Don Slutz wrote:
>> gdbsx_guest_mem_io() does not get d passed, it expects to handle
>> the domain lookup itself.
>>
>> Signed-off-by: Don Slutz
>> CC: Don Slutz
>
> As for the change itself, Reviewed-by: Andrew Cooper
>
>
> However,
flight 58718 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 58451
test-amd64-amd64
On 06/18/2015 09:46 PM, Abhinav Gupta wrote:
> Thanks for the reply Razvan, but I meant how will i test my code, when I
> make some changes ?
I was answering what I thought was your question about "not being able
to find any link for [...] development environment setup". If you mean
you'd like to
On 06/18/2015 09:40 PM, Abhinav Gupta wrote:
> Hello Xen developers,
> I'm new here. I'm not able to find any link for bugs/issues or
> development environment setup
> for xen. Please can anyone help me with this.
http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
HTH,
Razvan
___
On Thu, Jun 18, 2015 at 1:54 PM, Guenter Roeck wrote:
> On 06/17/2015 11:53 PM, Frans Klaver wrote:
>>
>> On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd
>> wrote:
>>>
>>> On 10/06/2014 10:28 PM, Guenter Roeck wrote:
Various drivers implement architecture and/or device specific means to
>
Hello Xen developers,
I'm new here. I'm not able to find any link for bugs/issues or development
environment setup
for xen. Please can anyone help me with this.
Thanks,
Abhinav
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
Ian Campbell writes ("[PATCH OSSTEST v2 18/19] Debian: Collect kernel command
line from grub.cfg"):
> I'm going to want it in a subsequent patch
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Campbell writes ("[PATCH OSSTEST v2 16/19] Collect xen.efi into xendist and
install in appropriate place"):
> Previously these binaries would have been included in the regular
> ("tools") dist file, whereas they really belong in the xen one.
>
> Install into /boot/efi/EFI/osstest ready for us
Ian Campbell writes ("[PATCH OSSTEST v2 15/19] Debian: grub2: Use
GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)"):
> This overrides GRUB_CMDLINE_LINUX(_DEFAULT) which we were previously
> editing but only for the Xen entries, meaning that we don't switch to
> console=hvc0 for the native cases (i.e. don
Ian Campbell writes ("[PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the
non-special kernel case too."):
> XXX fold somewhere?
I don't mind it being in a patch by itself, but I do want a commit
message that tells me why, not just what.
Ian.
___
Ian Campbell writes ("[PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order
during install"):
> Debian inserts itself before any existing entries, including the PXE
> one, meaning we otherwise cannot remotely regroove the box. Preseed
> some commands to reset the boot order to BootCurrent i.e. ho
Ian Campbell writes ("[PATCH OSSTEST v2 19/19] Debian: Arrange to be able to
chainload a xen.efi from grub2"):
> Xen cannot (currently) be booted directly via the usual multiboot
> path on EFI systems of any arch. Instead it is necessary to either
> launch xen.efi direct from the UEFI shell or to
Ian Campbell writes ("[PATCH OSSTEST v2 03/19] ts-host-install: Split initrd
out of @installcmdline"):
> Other bootloaders handle this with an explicit separate option rather
> than parsing it out of the command line as pxelinux does. Prepare for
> supporting these.
Acked-by: Ian Jackson
__
Ian Campbell writes ("[PATCH OSSTEST v2 04/19] ts-host-install: split the "di"
from the "host" command line"):
> (i.e. the bit before/after the -- marker). When abstracting over
> different bootloaders in a future patch this will be convenient since
> it allows the code to add to either.
Acked-by
Ian Campbell writes ("[PATCH OSSTEST v2 07/19] Enable chain loading to local
disk for UEFI PXE systems."):
> First arrange for bootloader to be installed to removable media path,
> by using a new in Jessie preseed option. Then use that to chainload a
> bootloader from the disk.
The `removable med
>> Yes, this is an option. However, I thought this would actually be an
>> option you would
>> not like.
>>
> How so... I've been arguing for this the whole time?!?! :-O
>
> I'm sure I've put down a sketch of what I think the replenishment
> function should do in my first or second email in the thr
Ian Campbell writes ("[PATCH OSSTEST v2 17/19] Debian: Ignore xen-syms entries
in grub.cfg."):
> These can't (in general?) actually be booted.
They can't be booted at all. That they are included in the menu is a
bug in something.
Acked-by: Ian Jackson
_
On 18/06/15 17:37, Wei Liu wrote:
> It's set in code but never used. Detected by -Wunused-but-set-variable.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Having said this, I am about to archive this entire file in /dev/null
when I respin the libxl migration v2 series.
~Andrew
___
Ian Campbell writes ("[PATCH OSSTEST v2 14/19] Debian: grub2: Log full line
range of menuentry and submenu entries"):
> Is useful when debugging.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Campbell writes ("[PATCH OSSTEST v2 13/19] standalone: Prefer
./standalone.config to $HOME/.xen-osstest/config"):
> OSSTEST_CONFIG still trumps both.
This results in us having
standalone-config-example
production-config
production-config-cambridge
but
standalone.config
is actually
flight 58717 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail REGR. vs.
58528
test-amd64-i3
Ian Campbell writes ("[PATCH OSSTEST v2 12/19] ts-kernel-build: Support --reuse
to keep same build tree"):
> This is very useful when iterating over kernel configurations, since
> it avoids blowing away the build tree and all the existing built
> objects. The Linux build system does the right thin
Ian Campbell writes ("[PATCH OSSTEST v2 09/19] ts-kernel-build: Additional
kernel options for Mustang"):
> XXX We probably need a newer kernel to actually be useful.
This doesn't seem quite finished ?
> +setopt CONFIG_FHANDLE y
What does this do and do we care about it on other platforms ?
> +
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Campbell writes ("[PATCH OSSTEST v2 06/19] ts-host-install: Support UEFI
PXE boot using grub.efi"):
> Signed-off-by: Ian Campbell
> +sub setup_grub_efi_bootcfg ($$) {
> +my ($ho, $bootfile) = @_;
> +my $f = "grub.cfg-$ho->{Ether}";
> +my $grub= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{G
When sending an event, use a new per-event channel lock to safely
validate the event channel state.
This new lock must be held when changing event channel state. Note
that the event channel lock must also be held when changing state from
ECS_FREE or it will race with a concurrent get_free_port()
Ian Campbell writes ("[PATCH OSSTEST v2 05/19] Refactor pxelinux
configuration"):
> The mechanism used to PXE boot can differ depending on the firmware
> type. Therefore refactor into Osstest::TestSupport and key off a new
> host property "firmware".
>
> Currently supported is "bios" (the default
Performance results for aggregate intrahost network throughput
(between 20 VM pairs, with 16 dom0 VCPUs) show substantial
improvements.
Throughput/Gbit/s
Base 9.7
Split locks 25.8
Split locks 42.9
+ per-VCPU
From: Malcolm Crossley
Performance analysis of aggregate network throughput with many VMs
shows that performance is signficantly limited by contention on the
maptrack lock when obtaining/releasing maptrack handles from the free
list.
Instead of a single free list use a per-VCPU list. This avoids
If a guest is not evenly grant mapping across its VCPUs one of the
VCPUs may run out of free maptrack entries even though other VCPUs
have many free.
If this happens, "steal" free entries from other VCPUs. We want to
steal entries such that:
a) We avoid ping-ponging stolen entries between VCPUs.
Ian Campbell writes ("[PATCH OSSTEST v2 02/19] Debian: Preseed a EFI system
partition during host install"):
> AIUI the runes used will only result in an ESP if the system was
> booted via UEFI. IOW I don't think there should be any change for
> existing systems.
OK, good.
Acked-by: Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v2 01/19] Introduce mg-pxe-loader-update"):
> The story for PXE booting via UEFI (at least on arm64) is not so
> straightforward as with pxelinux on x86. There seems to no good
> bootloader to launch via UEFI+pxe, in fact all I could find was grub
> (syslinux, a
On 18/06/15 16:55, Don Slutz wrote:
> gdbsx_guest_mem_io() does not get d passed, it expects to handle
> the domain lookup itself.
>
> Signed-off-by: Don Slutz
> CC: Don Slutz
As for the change itself, Reviewed-by: Andrew Cooper
However, I think the commit message needs improving. Specificall
Freeing a xen event channel would clear xen_consumer before clearing
the channel state, leaving a window where the channel is in a funny
state (still bound but no consumer).
Move the clear of xen_consumer into free_evtchn() where the state is
also cleared.
Signed-off-by: David Vrabel
---
v4:
- c
The number of struct evtchn in a page must be a power of two. Under
some workloads performance is improved slightly by padding struct
evtchn to 64 bytes (a typical cache line size), thus putting the fewer
per-channel locks into each cache line.
This does not decrease the number of struct evtchn's
notify_via_xen_event_channel() and free_xen_event_channel() had to
check if the domain was dying because they may be called while the
domain is being destroyed and the struct evtchn's are being freed.
By deferring the freeing of the struct evtchn's until all references
to the domain are dropped, t
The per-domain event channel lock limits scalability when many VCPUs
are trying to send interdomain events. A per-channel lock is
introduced eliminating any lock contention when sending an event.
See this graph for the performance improvements:
http://xenbits.xen.org/people/dvrabel/evtchn-scal
Hi David,
On 19/05/15 16:39, David Vrabel wrote:
> On 14/05/15 18:01, Julien Grall wrote:
>> The hypercall interface (as well as the toolstack) is always using 4KB
>> page granularity. When the toolstack is asking for mapping a series of
>> guest PFN in a batch, it expects to have the page map con
It's set in code but never used. Detected by -Wunused-but-set-variable.
Signed-off-by: Wei Liu
---
tools/libxc/xc_domain_save.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 301e770..3222473 100644
---
On 18/06/15 16:55, Don Slutz wrote:
> This allows reading and writing of variables in the hypervisor.
>
> for example (read case -- default 4 bytes):
>
> xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level
> opt_hvm_debug_level @ 0x82d080285610 is 0x0(0)
>
> Write case:
>
> xen-hyp-rw /b
Signed-off-by: Wei Liu
---
An additional patch to deal with new package name in libvirt toolstack code.
---
Osstest/Toolstack/libvirt.pm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e7f4860..c71f88a 1006
I'm going to want it in a subsequent patch
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8f4c4ea..d342103 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -460,15 +4
(i.e. the bit before/after the -- marker). When abstracting over
different bootloaders in a future patch this will be convenient since
it allows the code to add to either.
Signed-off-by: Ian Campbell
---
ts-host-install | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-
Signed-off-by: Ian Campbell
---
Osstest/TestSupport.pm | 37 -
README | 1 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 622f44d..1164a11 100644
--- a/Osstest/TestSupport.
Xen cannot (currently) be booted directly via the usual multiboot
path on EFI systems of any arch. Instead it is necessary to either
launch xen.efi direct from the UEFI shell or to chainload it from
grub. In both cases the Xen command line as well as what would
normally be the multiboot modules (ke
This is very useful when iterating over kernel configurations, since
it avoids blowing away the build tree and all the existing built
objects. The Linux build system does the right thing when .config
changes and only rebuilds the affected bits.
Signed-off-by: Ian Campbell
---
ts-kernel-build | 1
The mechanism used to PXE boot can differ depending on the firmware
type. Therefore refactor into Osstest::TestSupport and key off a new
host property "firmware".
Currently supported is "bios" (the default) and "uboot", both of which
use pxelinux.cfg style files.
The default for the firmware prop
OSSTEST_CONFIG still trumps both.
Signed-off-by: Ian Campbell
---
standalone | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/standalone b/standalone
index 17fa40c..ad12bad 100755
--- a/standalone
+++ b/standalone
@@ -68,7 +68,13 @@ TEMP=$(getopt -o c:f:h:rRs --long
co
Runvars:
build-arm64 arch
arm64
build-arm64 build_lvextend_max
50
build-arm64 enable_ovmf
true
build-arm64
The following makes a start on support for arm64 systems.
Since arm64 was only added in Debian Jessie this requires Wei's "Debian
Jessie patches" as a base line, I'm using v3 of those (note that these
have picked up some of the patches which I previously included in this
series, since they belong
flight 58716 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs.
AIUI the runes used will only result in an ESP if the system was
booted via UEFI. IOW I don't think there should be any change for
existing systems.
Signed-off-by: Ian Campbell
---
Osstest.pm| 1 +
Osstest/Debian.pm | 6 ++
2 files changed, 7 insertions(+)
diff --git a/Osstest.pm b/
The story for PXE booting via UEFI (at least on arm64) is not so
straightforward as with pxelinux on x86. There seems to no good
bootloader to launch via UEFI+pxe, in fact all I could find was grub
(syslinux, and by extension pxelinux.efi, is x86 only).
Add mg-pxe-loader-update modelled on mg-debi
Is useful when debugging.
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c6687db..d2a7be9 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -412,8 +412,7 @@ sub set
These can't (in general?) actually be booted.
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 31aa1e6..8f4c4ea 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -427,6 +427,9 @@ sub setup
Previously these binaries would have been included in the regular
("tools") dist file, whereas they really belong in the xen one.
Install into /boot/efi/EFI/osstest ready for use when chainloading.
Note that /boot/efi is (or should be) a VFAT filesystem. So a bit of
care is needed WRT symlinks et
XXX We probably need a newer kernel to actually be useful.
Signed-off-by: Ian Campbell
---
ts-kernel-build | 12
1 file changed, 12 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index 47ddf6f..4014a6c 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -526,6 +526,
Other bootloaders handle this with an explicit separate option rather
than parsing it out of the command line as pxelinux does. Prepare for
supporting these.
Signed-off-by: Ian Campbell
---
ts-host-install | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ts-host-install
Debian inserts itself before any existing entries, including the PXE
one, meaning we otherwise cannot remotely regroove the box. Preseed
some commands to reset the boot order to BootCurrent i.e. how we
booted (so the PXE entry).
There is still a window between the Debian entry being added (by
grub
First arrange for bootloader to be installed to removable media path,
by using a new in Jessie preseed option. Then use that to chainload a
bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which
saves us having to worry about which OS is on the host (so long
XXX fold somewhere?
---
ts-host-install | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-host-install b/ts-host-install
index 4e60e6e..6b18800 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -255,6 +255,9 @@ END
if -e "$ho->{Tftp}{Path}/$d_i/$kp-dtbs";
}
+$xop
This overrides GRUB_CMDLINE_LINUX(_DEFAULT) which we were previously
editing but only for the Xen entries, meaning that we don't switch to
console=hvc0 for the native cases (i.e. don't break them).
We do however want to edit GRUB_CMDLINE_LINUX(_DEFAULT) to remove
"quiet" if present, since it is us
On Thu, 2015-06-18 at 16:18 +0100, Ian Campbell wrote:
> On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote:
> > The "No response from client ..." appear only on armhf as far as I can
> > tell.
>
> Indeed, and I just noticed while developing osstest for arm64 that the
> daemon is segfaulting,
On Thu, 2015-06-18 at 16:33 +0100, Ian Jackson wrote:
> Ian Jackson writes ("[OSSTEST PATCH 01/25] Osstest.pm: Provide new db_prepare
> helper with built-in debugging"):
> > No callers, so no functional change, as yet.
>
> > +sub db_prepare ($) {
> > +# caller must ensure global filehandle DE
Ian Jackson writes ("[OSSTEST PATCH 01/25] Osstest.pm: Provide new db_prepare
helper with built-in debugging"):
> No callers, so no functional change, as yet.
> +sub db_prepare ($) {
> +# caller must ensure global filehandle DEBUG is open
> +my ($stmt) = @_;
> +print ::DEBUG "DB PREPA
On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote:
> The "No response from client ..." appear only on armhf as far as I can
> tell.
Indeed, and I just noticed while developing osstest for arm64 that the
daemon is segfaulting, and we even managed to collect a core dump, not
this time but in:
Jan Beulich writes ("4.5 qemu tree tagging"):
> could you please tag the respective qemu trees for 4.5.1? Considering
> the little (if any at all) testing feedback we've been getting on stable
> RCs, and considering how late we are with it, I actually see no point in
> doing another RC, so unless o
gdbsx_guest_mem_io() does not get d passed, it expects to handle
the domain lookup itself.
Signed-off-by: Don Slutz
CC: Don Slutz
---
xen/common/domctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index ce517a7..2a2d203 100644
--- a/xen/common/
The 1st patch just skips calling rcu_lock_domain_by_id() for
XEN_DOMCTL_gdbsx_guestmemio.
The code that handles XEN_DOMCTL_gdbsx_guestmemio, does not use d
and has it's own domain checking code.
The 2nd patch is an example tool thats uses
XEN_DOMCTL_gdbsx_guestmemio to read and modify the Hymberv
This allows reading and writing of variables in the hypervisor.
for example (read case -- default 4 bytes):
xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level
opt_hvm_debug_level @ 0x82d080285610 is 0x0(0)
Write case:
xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level 4 -1
opt_h
On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:
> Hi,
>
> I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
> no clear idea about why Dom0 kernel panic.
Have you confirmed that this same kernel runs reliably natively on this
platform?
[...]
> / # Unable to handle kernel
Ian Campbell writes ("Re: [OSSTEST PATCH 00/25] Reporting improvements"):
> On Thu, 2015-06-18 at 12:21 +0100, Ian Jackson wrote:
> > I'll give you a chance to look at the output URL above.
>
> Looks good, thanks.
>
> OOI what is the expected usefulness of the "alloc testid" column?
With the sys
On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote:
[ ... ]
>
> What happened to this series? I want to add shutdown support to my
> platform and I need to write a register on the PMIC in one driver to
> configure it for shutdown instead of restart and then write an MMIO
> register to te
On 18/06/15 15:09, Peng Fan wrote:
> Hi,
Hi,
> /bin/sh: can't access tty; job control turned off
> / # mmcblk2: p1 p2
> mmcblk2boot1: unknown partition table
> mmcblk2boot0: unknown partition table
> (XEN) imx-uart.c:72: uart: rxfifo overrun
It seems that you ported a new UART driver. My feelin
On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote:
> >>> On 17.06.15 at 12:26, wrote:
> > Jan Beulich writes ("stable trees (was: [xen-4.2-testing test] 58584:
> > regressions)"):
> >> Which leaves several options:
> >> - the problem was always there, but hidden by some factor in the
> >> ol
On Thu, 2015-06-18 at 12:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 00/25] Reporting improvements"):
> > On Wed, 2015-06-17 at 17:44 +0100, Ian Jackson wrote:
> > > Most of the early part of this series is straightforward (and acked)
> > > and could go in whenever.
> >
>>> On 11.06.15 at 10:28, wrote:
> --- a/xen/arch/x86/acpi/cpufreq/intel_pstate.c
> +++ b/xen/arch/x86/acpi/cpufreq/intel_pstate.c
> @@ -749,6 +749,9 @@ static struct cpufreq_driver intel_pstate_driver = {
> .name = "intel_pstate",
> };
>
> +static bool_t __initdata load_intel_psta
>>> On 11.06.15 at 10:27, wrote:
> The intel_pstate driver is ported following its kernel code logic
> (commit: 93f0822d).In order to port the Linux source file with
> minimal modifications, some of the variable types are kept intact
> (e.g. "int current_pstae", would otherwise be changed to
> "un
Hi,
I'm John's colleague. We looked into the details of the tracing data, and found
that the number of MSR_IA32_APICTMICT_MSR
event is quite high when apic-v is enabled(about 9x more compared with apic-v
disabled).
Below is the details:
EXIT_REASON_MSR_WRITE
apicv on:
MSR= 0x0838(MSR_IA32
>>> On 11.06.15 at 10:27, wrote:
> Register the CPU hotplug notifier when the driver is
> registered, and move the driver register function to
> the cpufreq.c.
The first half of the sentence fails to say why. And I suppose if you
explained that (to yourself) you'd figure that the change is wrong
>>> On 11.06.15 at 10:26, wrote:
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -457,6 +457,12 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
> data->min = policy->min;
> data->max = policy->max;
>
> +if (cpufreq_driver->setpolicy) {
> +
Hi,
I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.
Detail log see below:
U-Boot 2015.04-rc4-00145-gf12a16e (Jun 18 2015 - 10:38:06)
CPU: Freescale i.MX7D rev1.0 at 792 MHz
CPU: Thermal invalid data, fuse: 0x1b800
CPU: Tempera
>>> On 11.06.15 at 10:26, wrote:
> The added calculation related functions will be used in the intel_pstate.c.
> They are copied from the kernel(commit 2418f4f2, f3002134, eb18cba7).
The _Linux_ kernel I assume?
> --- a/xen/include/asm-x86/div64.h
> +++ b/xen/include/asm-x86/div64.h
> @@ -11,4 +
>>> On 11.06.15 at 10:25, wrote:
> Add a common interface for matching the current cpu against an
> array of x86_cpu_ids. Also change mwait-idle.c to use it.
>
> Signed-off-by: Wei Wang
> ---
There's a summary of the changes in v3 missing here (and it looks
like everywhere in the series). Putti
>>> On 18.06.15 at 15:29, wrote:
> On 18/06/15 13:51, Jan Beulich wrote:
>> -void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
>> +void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
>> {
>> +struct domain *d = vlapic_domain(vlapic);
>> +
>> if ( vlapic_test_and
flight 58713 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58713/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-xsm 11 guest-start fail like 58643
test-amd64-i386-libvirt 11 gu
On 18/06/15 14:14, Jan Beulich wrote:
> The number of slots per page being 511 (i.e. not a power of two) means
> that the (32-bit) read and write indexes going beyond 2^32 will likely
> disturb operation. Extend I/O req server creation so the caller can
> indicate that it is using suitable atomic a
On 18/06/15 13:51, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -421,18 +421,17 @@ void vlapic_EOI_set(struct vlapic *vlapi
> if ( hvm_funcs.handle_eoi )
> hvm_funcs.handle_eoi(vector);
>
> -if ( vlapic_test_and_clear_vector(vector,
flight 58714 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58714/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58681
test-amd64-i386-xl-qemuu-win7-amd64 1
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. The hypervisor side gets I/O req server creation
extended so we can indicate that we're using suitable atomic accesses
where needed (not a
1 - 100 of 180 matches
Mail list logo
