[Xen-devel] [ovmf test] 91514: regressions - FAIL

flight 91514 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91514/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

[Xen-devel] [qemu-mainline test] 91477: tolerable FAIL - PUSHED

flight 91477 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/91477/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 86454

Re: [Xen-devel] Bug in x86 instruction emulator?

On 2016-04-15 19:44, Andrew Cooper wrote: On 15/04/16 18:33, wo...@openmailbox.org wrote: On 2016-04-07 04:04, Jan Beulich wrote: We'd need to know which exact exception (including error code and, in the case of #PF, CR2 value) gets raised to the guest by what specific piece of code in the

[Xen-devel] [linux-linus test] 91416: regressions - FAIL

flight 91416 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/91416/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254

[Xen-devel] [linux-3.18 test] 91420: regressions - FAIL

flight 91420 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/91420/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 20 leak-check/check fail REGR. vs. 86513

[Xen-devel] [libvirt test] 91479: tolerable FAIL - PUSHED

flight 91479 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/91479/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14

[Xen-devel] [PATCH] xen/x86: don't lose event interrupts

On slow platforms with unreliable TSC, such as QEMU emulated machines, it is possible for the kernel to request the next event in the past. In that case, in the current implementation of xen_vcpuop_clockevent, we simply return -ETIME. To be precise the Xen returns -ETIME and we pass it on. However

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

(Sorry, just realised I never replied to this) On Wed, 13 Apr, at 01:59:10PM, Roger Pau Monné wrote: > > Is this header compatible with the ELF header? Con both co-exist in the > same binary without issues? Nope, they cannot. We get away with mixing bzImage headers and PE/COFF headers for the

[Xen-devel] [linux-3.16 test] 91397: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 91397 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/91397/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 3 host-install(3) broken pass in 91249 test-amd64-amd64-libvirt-pair 21

Re: [Xen-devel] [PATCH libvirt v2 2/2] libxl: support vscsi

On 04/13/2016 03:15 AM, Olaf Hering wrote: > This uses the API version of the proposed vscsi support in libxl (v12): > http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg01772.html We'll need to wait for that to land in xen.git before committing libxl scsi support to libvirt.git, but

Re: [Xen-devel] [PATCH libvirt v2 1/2] libxl: include a XLU_Config in _libxlDriverConfig

On 04/13/2016 03:15 AM, Olaf Hering wrote: > 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

Re: [Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

On Fri, 15 Apr 2016, Guenter Roeck wrote: > On Fri, Apr 15, 2016 at 11:22:36AM -0700, Stefano Stabellini wrote: > > On Thu, 14 Apr 2016, Guenter Roeck wrote: > > > Register with kernel restart handler instead of setting arm_pm_restart > > > directly. > > > > > > Select a high priority of 192 to

[Xen-devel] [xen-unstable test] 91384: regressions - FAIL

flight 91384 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/91384/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail REGR. vs. 86491

Re: [Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

On Fri, Apr 15, 2016 at 11:22:36AM -0700, Stefano Stabellini wrote: > On Thu, 14 Apr 2016, Guenter Roeck wrote: > > Register with kernel restart handler instead of setting arm_pm_restart > > directly. > > > > Select a high priority of 192 to ensure that default restart handlers > > are replaced

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, 15 Apr 2016, Luis R. Rodriguez wrote: > On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall wrote: > > On 14/04/16 21:56, Luis R. Rodriguez wrote: > >> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: > >>> But to make that work you have to emulate

Re: [Xen-devel] [libvirt] [PATCH V2] libxl: use LIBXL_API_VERSION 0x040200

On 04/15/2016 03:48 AM, Martin Kletzander wrote: > On Thu, Apr 14, 2016 at 04:35:12PM -0600, Jim Fehlig wrote: >> To ensure the libvirt libxl driver will build with future versions >> of Xen where the libxl API may change in incompatible ways, >> explicitly use LIBXL_API_VERSION 0x040200. The

[Xen-devel] [PATCH for-4.7 0/5] build: fixes for building Xen with clang

This series contain small bug-fixes for building the Xen microkernel with clang. I think they are suitable for 4.7, but that's just my opinion. I've also noticed that Xen always sets "-no-integrated-as" when using clang, because previous versions (<3.8.0) didn't support .code16/.code32/.code64 in

[Xen-devel] [PATCH for-4.7 5/5] travis: add an alias for gcc when using clang

In order to prevent it's usage. Since the tests are run on a Linux system gcc is always present, so it's hard to detect if gcc is used in the clang build. Signed-off-by: Roger Pau Monné --- Cc: Doug Goldstein --- .travis.yml | 1 + 1 file changed, 1

[Xen-devel] [PATCH for-4.7 4/5] build: remove Kconfig forced gcc selection

Signed-off-by: Roger Pau Monné --- Cc: Doug Goldstein --- xen/tools/kconfig/Makefile.kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/tools/kconfig/Makefile.kconfig b/xen/tools/kconfig/Makefile.kconfig index

[Xen-devel] [PATCH for-4.7 3/5] build: pass HOST{CC/CXX} value down to Kconfig

Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- xen/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[Xen-devel] [PATCH for-4.7 2/5] build: set HOSTCXX based on clang value for Kconfig xconfig target

The xconfig Kconfig target requires a C++ compiler because it uses Qt. Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- Config.mk | 2 ++ 1

[Xen-devel] [PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

Previously HOSTCC was always hardcoded to gcc Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- Config.mk | 3 ++- 1 file changed, 2

Re: [Xen-devel] [PATCH v2 2/6] ARM: xen: Register with kernel restart handler

On Thu, 14 Apr 2016, Guenter Roeck wrote: > Register with kernel restart handler instead of setting arm_pm_restart > directly. > > Select a high priority of 192 to ensure that default restart handlers > are replaced if Xen is running. > > Acked-by: Arnd Bergmann > Reviewed-by:

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

On 04/15/16 20:38, Tamas K Lengyel wrote: > > > On Fri, Apr 15, 2016 at 11:19 AM, Razvan Cojocaru > > wrote: > > On 04/15/16 20:12, Tamas K Lengyel wrote: > > > > > > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru >

Re: [Xen-devel] Bug in x86 instruction emulator?

On 15/04/16 18:33, wo...@openmailbox.org wrote: > On 2016-04-07 04:04, Jan Beulich wrote: >> We'd need to know which exact exception (including error code and, >> in the case of #PF, CR2 value) gets raised to the guest by what >> specific piece of code in the hypervisor. That'll likely mean some

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

On Fri, Apr 15, 2016 at 11:19 AM, Razvan Cojocaru wrote: > On 04/15/16 20:12, Tamas K Lengyel wrote: > > > > > > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru > > > wrote: > > > > Previously,

Re: [Xen-devel] Bug in x86 instruction emulator?

On 2016-04-07 04:04, Jan Beulich wrote: We'd need to know which exact exception (including error code and, in the case of #PF, CR2 value) gets raised to the guest by what specific piece of code in the hypervisor. That'll likely mean some instrumentation of the hypervisor code. Jan I want to

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

On Fri, Apr 15, 2016 at 11:18 AM, Andrew Cooper wrote: > On 15/04/16 18:12, Tamas K Lengyel wrote: > > > > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru < > rcojoc...@bitdefender.com> wrote: > >> Previously, subscribing to MSR write events

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 05:03:07PM +0100, George Dunlap wrote: > On 15/04/16 16:30, Luis R. Rodriguez wrote: > > On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote: > >> On 14/04/16 20:44, Luis R. Rodriguez wrote: > >>> No, I meant to ask, would it be possible to make booting HVMLite

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

On 04/15/16 20:12, Tamas K Lengyel wrote: > > > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru > > wrote: > > Previously, subscribing to MSR write events was an all-or-none > approach, with special cases for introspection

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru wrote: > Previously, subscribing to MSR write events was an all-or-none > approach, with special cases for introspection MSR-s. This patch > allows the vm_event consumer to specify exactly what MSR-s it is > interested

Re: [Xen-devel] [PATCH V3] vm_event: Allow subscribing to write events for specific MSR-s

On 15/04/16 18:12, Tamas K Lengyel wrote: > > > On Fri, Apr 15, 2016 at 3:02 AM, Razvan Cojocaru > > wrote: > > Previously, subscribing to MSR write events was an all-or-none > approach, with special cases for introspection

Re: [Xen-devel] x86 patch ping

On 08/04/16 13:10, Jan Beulich wrote: > http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html > (with the 1st patch having gone in already) Apologies for the delay on this. I now have results in. The 64bit performance hit is within the noise (as expected) but sadly, the performance

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:02:47PM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote: > > Are you telling me that HVMLite has no dead code issues ? > > You said earlier that baremetal has dead code issue. Then by extensions > _any_ execution

Re: [Xen-devel] Code Review Dashboard (nearly-complete)

> On 14 Apr 2016, at 16:43, Wei Liu wrote: > > The way the documentation is arranged is not very > structural and the glossary is missing at the moment. I think that can > be improved. See http://wiki.xenproject.org/wiki/Code_Review_Dashboard Lars

Re: [Xen-devel] [PATCHv8] x86/ept: defer the invalidation until the p2m lock is released

On Tue, Apr 12, 2016 at 5:19 PM, David Vrabel wrote: > Holding the p2m lock while calling ept_sync_domain() is very expensive > since it does an on_selected_cpus() call. IPIs on many socket > machines can be very slow and on_selected_cpus() is serialized. > > It is safe

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 15/04/16 16:30, Luis R. Rodriguez wrote: > On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote: >> On 14/04/16 20:44, Luis R. Rodriguez wrote: >>> No, I meant to ask, would it be possible to make booting HVMLite using EFI >>> be optional ? That way if you already support EFI that can

Re: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

On Fri, Apr 15, 2016 at 04:54:16PM +0200, Juergen Gross wrote: > Subject: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in > xc_cpupool_removecpu() > List-Id: Xen developer discussion > > Commit 1ef6beea187b ("libxc: do some retries in xc_cpupool_removecpu() > for EBUSY case") added a

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

On 15/04/16 17:25, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* > error codes"): >> Requested-by: Ian Jackson >> Signed-off-by: Juergen Gross > > Acked-by: Ian Jackson > >

Re: [Xen-devel] [PATCH v3 03/16] x86/boot: call reloc() using cdecl calling convention

On 15/04/16 13:33, Daniel Kiper wrote: > reloc() is not called according to cdecl calling convention. > This makes confusion and does not scale well for more arguments. > And patch adding multiboot2 protocol support have to pass 3 > arguments instead of 2. Hence, move reloc() call to cdecl >

Re: [Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

On 15/04/16 13:33, Daniel Kiper wrote: > Speedup BSS initialization by using stosl instead of stosb. > > Some may argue that Intel Ivy Bridge and later provide ERMSB feature. > This means that "rep stosb" gives better throughput than "rep stosl" on > above mentioned CPUs. However, this feature is

Re: [Xen-devel] [PATCH v3 01/16] x86/boot: do not create unwind tables

On 15/04/16 13:33, Daniel Kiper wrote: > This way .eh_frame section is not included in *.lnk and *.bin files. > Hence, final e.g. reloc.bin file size is reduced from 408 bytes to > 272 bytes and it contains only used code and data. > > Suggested-by: Jan Beulich > Signed-off-by:

Re: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

On Fri, 2016-04-15 at 16:19 +0100, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 2/3] libxc: adjust retry loop in > xc_cpupool_removecpu()"): > > > > Commit 1ef6beea187b ("libxc: do some retries in > > xc_cpupool_removecpu() > > for EBUSY case") added a retry loop in xc_cpupool_removecpu()

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes"): > Requested-by: Ian Jackson > Signed-off-by: Juergen Gross Acked-by: Ian Jackson Thanks this is very helpful. I think it should go

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote: > On 14/04/16 20:44, Luis R. Rodriguez wrote: > > No, I meant to ask, would it be possible to make booting HVMLite using EFI > > be optional ? That way if you already support EFI that can be used on > > your entires with some small

Re: [Xen-devel] [PATCH 1/3] xen: return different error values for cpupool operations

On Fri, 2016-04-15 at 16:18 +0100, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 1/3] xen: return different error values > for cpupool operations"): > > > > Today there are several different situations in which moving a cpu > > from or to a cpupool will return -EBUSY. This makes it hard for

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 07:50:25AM +0200, Juergen Gross wrote: > On 14/04/16 21:44, Luis R. Rodriguez wrote: > > No, I meant to ask, would it be possible to make booting HVMLite using EFI > > be optional ? That way if you already support EFI that can be used on > > your entires with some small

Re: [Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

Juergen Gross writes ("[PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()"): > Commit 1ef6beea187b ("libxc: do some retries in xc_cpupool_removecpu() > for EBUSY case") added a retry loop in xc_cpupool_removecpu() for the > EBUSY case. As EBUSY was returned in multiple error

Re: [Xen-devel] [PATCH 1/3] xen: return different error values for cpupool operations

Juergen Gross writes ("[PATCH 1/3] xen: return different error values for cpupool operations"): > Today there are several different situations in which moving a cpu > from or to a cpupool will return -EBUSY. This makes it hard for the > user to know what he did wrong, as the Xen tools are not

[Xen-devel] [linux-4.1 baseline-only test] 44333: regressions - FAIL

This run is configured for baseline tests only. flight 44333 linux-4.1 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44333/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-midway 15

Re: [Xen-devel] [PATCH 0/3] adjust error return values for cpupool operations

On Fri, Apr 15, 2016 at 04:54:14PM +0200, Juergen Gross wrote: > Some cpupool operations return the same error value for multiple > situations. This makes it hard for the tools to react accordingly e.g. > by issuing a suitable error message. > > Return appropriate error values and document them.

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall wrote: > On 14/04/16 21:56, Luis R. Rodriguez wrote: >> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: >>> But to make that work you have to emulate EFI firmware in the >>> hypervisor. Is that work you are

[Xen-devel] [PATCH 1/3] xen: return different error values for cpupool operations

Today there are several different situations in which moving a cpu from or to a cpupool will return -EBUSY. This makes it hard for the user to know what he did wrong, as the Xen tools are not capable to print a detailed error message. Depending on the situation return different error codes in

[Xen-devel] [PATCH 0/3] adjust error return values for cpupool operations

Some cpupool operations return the same error value for multiple situations. This makes it hard for the tools to react accordingly e.g. by issuing a suitable error message. Return appropriate error values and document them. Juergen Gross (3): xen: return different error values for cpupool

[Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

Requested-by: Ian Jackson Signed-off-by: Juergen Gross --- xen/include/public/sysctl.h | 36 1 file changed, 36 insertions(+) diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index

[Xen-devel] [PATCH 2/3] libxc: adjust retry loop in xc_cpupool_removecpu()

Commit 1ef6beea187b ("libxc: do some retries in xc_cpupool_removecpu() for EBUSY case") added a retry loop in xc_cpupool_removecpu() for the EBUSY case. As EBUSY was returned in multiple error situations the loop would have been executed in situations where a retry would not be successful.

Re: [Xen-devel] domain crashed when using VMFUNC

> On 15 Apr 2016, at 10:15 PM, Tamas K Lengyel > wrote: > > > On Apr 15, 2016 07:46, "liuweijie" > wrote: > > > > Dear list, > > > > When I use VMFUNC instructions on a Xen HVM, domain crashes sometimes. > > > > My

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

Juergen Gross writes ("Re: [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > On 15/04/16 16:12, Ian Jackson wrote: > > Does the hypervisor currently use EAGAIN for anything ? > > Yes. Especially XEN_SYSCTL_CPUPOOL_OP_RMCPU can return it already. That is a good

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On 15/04/16 16:11, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document > XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): >> Just saw there are still two cases left where EBUSY will be returned: >> >> - when trying to remove the last cpu from a cpupool with

[Xen-devel] [ovmf test] 91423: regressions - FAIL

flight 91423 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91423/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-build fail REGR. vs. 65543 build-amd64

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On 15/04/16 16:12, Ian Jackson wrote: > Dario Faggioli writes ("Re: [PATCH 3/3] xen: Document > XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): >> However, a different return value for the super special case of >> temporary pinning override could maybe be selected. I'm having a look, >> and

[Xen-devel] [xen-unstable-smoke test] 91497: tolerable all pass - PUSHED

flight 91497 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/91497/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] block-iscsi with Xen 4.5 / 4.6

On 16/04/2016 12:30 AM, George Dunlap wrote: > On Fri, Apr 15, 2016 at 7:59 AM, Steven Haigh wrote: >> Hi all, >> >> I'm wading through the somewhat confusing world of documentation regarding >> storing DomU disk images on an iSCSI target. >> >> I'm getting an error when using

Re: [Xen-devel] block-iscsi with Xen 4.5 / 4.6

On Fri, Apr 15, 2016 at 7:59 AM, Steven Haigh wrote: > Hi all, > > I'm wading through the somewhat confusing world of documentation regarding > storing DomU disk images on an iSCSI target. > > I'm getting an error when using pygrub of: > OSError: [Errno 2] No such file or

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On Fri, Apr 15, 2016 at 03:12:56PM +0100, Ian Jackson wrote: > Dario Faggioli writes ("Re: [PATCH 3/3] xen: Document > XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > > However, a different return value for the super special case of > > temporary pinning override could maybe be selected.

Re: [Xen-devel] domain crashed when using VMFUNC

On Apr 15, 2016 07:46, "liuweijie" wrote: > > Dear list, > > When I use VMFUNC instructions on a Xen HVM, domain crashes sometimes. > > My serial console shows like this: > > domain_crash called from p2m.c:2204 > Domain 1 (vcpu#0) crashed on cpu#7 > …… > > My testbed runs on

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

Dario Faggioli writes ("Re: [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > However, a different return value for the super special case of > temporary pinning override could maybe be selected. I'm having a look, > and although I don't find one that could be seen

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

Juergen Gross writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > Just saw there are still two cases left where EBUSY will be returned: > > - when trying to remove the last cpu from a cpupool with active domains > (EBUSY seems appropriate)

Re: [Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

> diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds > new file mode 100644 > index 000..47db9c4 > --- /dev/null > +++ b/xen/arch/x86/boot/build32.lds > @@ -0,0 +1,49 @@ > +/* > + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved. > + * Daniel

Re: [Xen-devel] abstract model of IOMMU unmaping/mapping failures

On 31/03/16 10:06, Xu, Quan wrote: > All, > > Here is a summary of my investigation of the abstract model: > > Below policies are adopted when deciding whether to rollback a callchain: > > 1. Domain will be crashed immediately within iommu_{,un}map_page, treated as > a fatal error (with the

Re: [Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

On Fri, Apr 15, 2016 at 02:33:02PM +0200, Daniel Kiper wrote: > Speedup BSS initialization by using stosl instead of stosb. > > Some may argue that Intel Ivy Bridge and later provide ERMSB feature. > This means that "rep stosb" gives better throughput than "rep stosl" on > above mentioned CPUs.

[Xen-devel] domain crashed when using VMFUNC

Dear list, When I use VMFUNC instructions on a Xen HVM, domain crashes sometimes. My serial console shows like this: domain_crash called from p2m.c:2204 Domain 1 (vcpu#0) crashed on cpu#7 …… My testbed runs on Xen-4.6.0, and my CPU is Intel i7-4790. I can provide more logs if needed. I know

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On Fri, 2016-04-15 at 15:20 +0200, Juergen Gross wrote: > On 15/04/16 12:58, Dario Faggioli wrote: > > > > On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote: > > >  > > > The EBUSY returns of not successful repair attempts (trying to > > > assign > > > a > > > cpu to another cpupool) should

Re: [Xen-devel] abstract model of IOMMU unmaping/mapping failures

On 12/04/16 04:30, Xu, Quan wrote: > George, > > In this discussion, most of them are memory-related problems. Your comments > are valuable. > If you have read this thread, could you give me some feedback? I really > appreciate your precious advice. Sorry -- I was trying to get all the stuff

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On 15/04/16 12:58, Dario Faggioli wrote: > On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote: >> On 15/04/16 12:20, Ian Jackson wrote: >>> >>> Would either of you care to provide a version of my documentation >>> patch >>> which answers the questions that my text answers ? Or shall we >>>

Re: [Xen-devel] Side channel attack

On Fri, 15 Apr 2016 15:49:20 +0800 Zakirasafi wrote: > The following code is for side channel attack on xen hypevisor. In this > code I am having problem in understanding the highlighted red line. In the > line what ".byte 15, byte 49" do??? You can use this trick in the future: $ printf

Re: [Xen-devel] Side channel attack

Hi Zakirasafi, > unsigned int timestamp(void) > { > unsigned int bottom; > unsigned int top; > *asm volatile(".byte 15;.byte 49" : "=a"(bottom),"=d"(top)); return bottom;* > } It is ‘RDTSC’ instruction. Besides, I am happy that someone is also working on side channel attack on Xen. Maybe we

[Xen-devel] [PATCH v3 15/16 - RFC] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 1

[Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper --- v3 - suggestions/fixes: -

[Xen-devel] [PATCH v3 06/16] x86/boot/reloc: Rename some variables and rearrange code a bit

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code a bit to make it more readable. Additionally, this way multiboot (v1) protocol implementation and future multiboot2 protocol implementation will use the same variable naming convention. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v3 11/16] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and going down. Sadly this does not work when Xen is loaded using multiboot2 protocol because start lives on 1 MiB address. So, I tried to use mem_lower address

[Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

First of all we need to differentiate between legacy BIOS and EFI platforms during runtime, not during build, because one image will have legacy and EFI code and can be executed on both platforms. Additionally, we need more fine grained knowledge about EFI environment and check for EFI platform

[Xen-devel] [PATCH v3 05/16] x86/boot: use %ecx instead of %eax

Use %ecx instead of %eax to store low memory upper limit from EBDA. This way we do not wipe multiboot protocol identifier. It is needed in reloc() to differentiate between multiboot (v1) and multiboot2 protocol. Signed-off-by: Daniel Kiper Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH v3 14/16] x86/boot: implement early command line parser in C

Current early command line parser implementation in assembler is very difficult to change to relocatable stuff using segment registers. This requires a lot of changes in very weird and fragile code. So, reimplement this functionality in C. This way code will be relocatable out of the box (without

[Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

Speedup BSS initialization by using stosl instead of stosb. Some may argue that Intel Ivy Bridge and later provide ERMSB feature. This means that "rep stosb" gives better throughput than "rep stosl" on above mentioned CPUs. However, this feature is only available on newer Intel processors and

[Xen-devel] [PATCH v3 16/16] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v3 13/16 - RFC] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v3 - suggestions/fixes: - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad

[Xen-devel] [PATCH v3 00/16] x86: multiboot2 protocol support

Hi, I am sending, long awaited, third version of multiboot2 protocol support for legacy BIOS and EFI platforms. It fixes all major issues discovered until now. There are still some minor problems which should be fixed in one way or another. I will address them in next releases. The final goal is

[Xen-devel] [PATCH v3 04/16] x86/boot/reloc: create generic alloc and copy functions

Create generic alloc and copy functions. We need separate tools for memory allocation and copy to provide multiboot2 protocol support. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- v3 - suggestions/fixes: - use "g" constraint instead of "r"

[Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does some code optimizations by creating data sections (e.g. jump addresses for C switch/case are calculated using data in .rodata section). This thing is not accepted by *.lnk build recipe which requires that only .text section

[Xen-devel] [PATCH v3 03/16] x86/boot: call reloc() using cdecl calling convention

reloc() is not called according to cdecl calling convention. This makes confusion and does not scale well for more arguments. And patch adding multiboot2 protocol support have to pass 3 arguments instead of 2. Hence, move reloc() call to cdecl calling convention. I add push %ebp/mov

[Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

Existing solution does not allocate space for this symbol and any references to acpi20, etc. does not make sense. As I saw any efi.* references are protected by relevant ifs but we should not do that because it makes code very fragile. If somebody does not know how efi symbol is created he/she may

[Xen-devel] [PATCH v3 01/16] x86/boot: do not create unwind tables

This way .eh_frame section is not included in *.lnk and *.bin files. Hence, final e.g. reloc.bin file size is reduced from 408 bytes to 272 bytes and it contains only used code and data. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper ---

[Xen-devel] [linux-mingo-tip-master test] 91379: regressions - FAIL

flight 91379 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/91379/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684

Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

On 15/04/16 12:58, Dario Faggioli wrote: > On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote: >> On 15/04/16 12:20, Ian Jackson wrote: >>> >>> Would either of you care to provide a version of my documentation >>> patch >>> which answers the questions that my text answers ? Or shall we >>>

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

On Thu, Apr 14, 2016 at 6:01 PM, Jan Beulich wrote: >>Sure, mistakes happen; but I hope it's not being to controversial to >>say that in general, the procedure should be arranged such that the >>person who makes the mistake is the one who has to do deal with the >>most

Re: [Xen-devel] [PATCH for-4.7] hotplug/Linux: fix same_vm check in block script

Wei Liu writes ("Re: [PATCH for-4.7] hotplug/Linux: fix same_vm check in block script"): > Release-acked-by: Wei Liu Queued, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7] tools/libxl: Fix legacy migration following COLO backchannel breakage

Wei Liu writes ("Re: [PATCH for-4.7] tools/libxl: Fix legacy migration following COLO backchannel breakage"): > Release-acked-by: Wei Liu > > Thank you for fixing this. Indeed, thanks everyone. Queued. Ian. ___ Xen-devel

Re: [Xen-devel] [PATCH v2] xen: change the sizes of memory fields in the HVM start info to be 64bits

Wei Liu writes ("Re: [PATCH v2] xen: change the sizes of memory fields in the HVM start info to be 64bits"): > On Wed, Apr 13, 2016 at 10:15:32PM -0600, Jan Beulich wrote: >>> Roger Pau Monne 04/12/16 6:12 PM >>> > > >At the moment the only consumer of this structure is

  1   2   >