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

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 directory: 'iqn=iqn.1986-03.com.sun:02:ff2d12c0-b709-4ec0-999d-976506c666f5,portal=192.

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

On Fri, Apr 15, 2016 at 04:59:11PM +1000, 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 directory: > '

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

On 2016-04-15 17:23, Roger Pau Monné wrote: On Fri, Apr 15, 2016 at 04:59:11PM +1000, 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

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

On Fri, 2016-04-15 at 07:35 +0200, Juergen Gross wrote: > On 14/04/16 19:07, Ian Jackson wrote: > >  > > --- a/xen/include/public/sysctl.h > > +++ b/xen/include/public/sysctl.h > > @@ -560,6 +560,34 @@ struct xen_sysctl_cpupool_op { > >  > > + * In this case the operation may have been partially ca

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

On Fri, Apr 15, 2016 at 05:28:12PM +1000, Steven Haigh wrote: > On 2016-04-15 17:23, Roger Pau Monné wrote: > > On Fri, Apr 15, 2016 at 04:59:11PM +1000, Steven Haigh wrote: > > > Hi all, > > > > > > I'm wading through the somewhat confusing world of documentation > > > regarding > > > storing Dom

Re: [Xen-devel] [PATCH 1/3] libxc: Revert "do some retries in xc_cpupool_removecpu() for EBUSY case"

On Fri, 2016-04-15 at 07:15 +0200, Juergen Gross wrote: > On 14/04/16 19:07, Ian Jackson wrote: > > > > libxc may be called from within long-running daemons such as > > libvirt. > > > > In such a system this sleep would enable an uncooperative or buggy > > guest to block all toolstack operations

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

On 2016-04-15 17:46, Roger Pau Monné wrote: On Fri, Apr 15, 2016 at 05:28:12PM +1000, Steven Haigh wrote: On 2016-04-15 17:23, Roger Pau Monné wrote: > On Fri, Apr 15, 2016 at 04:59:11PM +1000, Steven Haigh wrote: > > Hi all, > > > > I'm wading through the somewhat confusing world of documentati

[Xen-devel] Side channel attack

Dear All 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??? #include #include #include #include unsigned int timestamp(void) { unsigned int bottom; unsigned int

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

On Fri, Apr 15, 2016 at 05:48:24PM +1000, Steven Haigh wrote: > On 2016-04-15 17:46, Roger Pau Monné wrote: > > On Fri, Apr 15, 2016 at 05:28:12PM +1000, Steven Haigh wrote: > > > On 2016-04-15 17:23, Roger Pau Monné wrote: > > > > On Fri, Apr 15, 2016 at 04:59:11PM +1000, Steven Haigh wrote: > > >

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

On 2016-04-15 18:03, Roger Pau Monné wrote: On Fri, Apr 15, 2016 at 05:48:24PM +1000, Steven Haigh wrote: On 2016-04-15 17:46, Roger Pau Monné wrote: > On Fri, Apr 15, 2016 at 05:28:12PM +1000, Steven Haigh wrote: > > On 2016-04-15 17:23, Roger Pau Monné wrote: > > > On Fri, Apr 15, 2016 at 04:5

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

On 2016-04-15 18:11, Steven Haigh wrote: On 2016-04-15 18:03, Roger Pau Monné wrote: On Fri, Apr 15, 2016 at 05:48:24PM +1000, Steven Haigh wrote: On 2016-04-15 17:46, Roger Pau Monné wrote: > On Fri, Apr 15, 2016 at 05:28:12PM +1000, Steven Haigh wrote: > > On 2016-04-15 17:23, Roger Pau Monné

Re: [Xen-devel] Where and How the P2M table and M2P table create?

On Thu, Apr 14, 2016 at 7:37 AM, Yunqiang Gao wrote: > Hi,alls, > > As we know,in xen ,when create shadow page table and EPT page table,we need > the p2m and m2p.I want to know when are the p2m been created.Was it created > at the time of the creation of the domainU？Or at the beginning is a empty

Re: [Xen-devel] run xen on hikey board

thanks for your reply can you explain more .. which patch you mean.. writing " make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-" is not enough for building xen on hikey board !! because i didn't find any patch for xen Regards On Thu, Apr 14, 2016 at 9:13 PM, Julien G

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

On Thu, 2016-04-14 at 16:35 -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 libxl driver > does use new libxl APIs that have been added since

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

On Thu, Apr 14, 2016 at 08:54:15PM +0100, Andrew Cooper wrote: > c/s f5d947bf1b "tools/libxl: add back channel support to read stream" > made a bogus adjustment to libxl__stream_read_start(), including > removing the comment hinting at what was going on, which breaks > conversion of a legacy migrat

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

On Thu, Apr 14, Andrew Cooper wrote: > c/s f5d947bf1b "tools/libxl: add back channel support to read stream" > made a bogus adjustment to libxl__stream_read_start(), including > removing the comment hinting at what was going on, which breaks > conversion of a legacy migration stream. Thanks! Tes

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

On Fri, Apr 15, 2016 at 06:20:56PM +1000, Steven Haigh wrote: [...] > I might have spoken too soon here... I updated this system to 4.6.1 and > created the DomU again - still seems to fail - although it does actually > call the block-iscsi script this time: > > # xl -vvv create /etc/xen/test1.vm >

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

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 in, and as a side-effect gets rid of the vmx_introspection_force_enabled_msrs[] special case. T

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

> On 14 Apr 2016, at 16:43, Wei Liu wrote: > > On Thu, Apr 14, 2016 at 01:26:29PM +0100, Lars Kurth wrote: >> Hi folks, >> >> the code review dashboard is nearly complete. The read-only version is >> accessible via https://kibana.bitergia.com/xen >> >> We added plenty of documentation in the

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

On Fri, Apr 15, 2016 at 12:02:07PM +0300, 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 in, and as a side-effe

Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

On Thu, Apr 14, Ian Jackson wrote: > Dario Faggioli writes ("Re: [Xen-devel] Fixing libvirt's libxl driver > breakage -- where to define LIBXL_API_VERSION?"): > > And, in those cases, usage should be gated by the appropriate > > LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g., > > for 

Re: [Xen-devel] Update SeaBIOS to include 8a0df3

On Thu, Apr 14, 2016 at 06:51:04PM +0200, Roger Pau Monné wrote: > Hello, > > I would like to request an update of the SeaBIOS repository to include the > latest commits in the 1.9-stable branch. I'm only interested in commit > 8a0df3, which is basically our current version (rel-1.9.1) plus a bu

Re: [Xen-devel] run xen on hikey board

Hello, Please avoid top-posting on the mailing list. On 15/04/16 09:42, Safa Hamza wrote: thanks for your reply can you explain more .. which patch you mean.. writing " make dist-xen XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-" I meant adding earlyprintk support for the hikey bo

[Xen-devel] [distros-debian-jessie test] 44334: trouble: blocked/broken

flight 44334 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44334/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3863 host-install(3) broken REG

Re: [Xen-devel] Update SeaBIOS to include 8a0df3

On Fri, Apr 15, 2016 at 10:19:49AM +0100, Wei Liu wrote: > On Thu, Apr 14, 2016 at 06:51:04PM +0200, Roger Pau Monné wrote: > > Hello, > > > > I would like to request an update of the SeaBIOS repository to include the > > latest commits in the 1.9-stable branch. I'm only interested in commit > >

Re: [Xen-devel] Side channel attack

Hello Please don't post HTML mails. On Fri, Apr 15, 2016 at 03:49:20PM +0800, Zakirasafi wrote: > Dear All > 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??? >

Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.

On Wed, Apr 13, 2016 at 05:45:27PM +0800, Fu Wei wrote: > Hi Julien, > > On 8 April 2016 at 23:19, Julien Grall wrote: > > Hi Wei, > > > > On 08/04/16 15:58, Wei Liu wrote: > >> > >> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien Grall wrote: > >>> > >>> Hi Fu Wei, > >>> > >>> On 05/04/16 17:46

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

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 libxl driver does use new libxl APIs that have been added since

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

On Thu, Apr 14, 2016 at 07:13:29PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH for-4.7] hotplug/Linux: fix same_vm check in block > script"): > > The original same_vm check has two bugs. When stubdom is in use because > > it relies on numeric domid to check if two domains are in fact the s

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

On 14/04/16 20:44, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote: >> On 13/04/16 20:52, Luis R. Rodriguez wrote: >>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote: On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote: > So more

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

Hello Luis, On 14/04/16 21:56, Luis R. Rodriguez wrote: On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote: On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: On Thu, Apr 14, 2016 at 12:2

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

On 15/04/2016 7:01 PM, Roger Pau Monné wrote: > On Fri, Apr 15, 2016 at 06:20:56PM +1000, Steven Haigh wrote: > [...] >> I might have spoken too soon here... I updated this system to 4.6.1 and >> created the DomU again - still seems to fail - although it does actually >> call the block-iscsi script

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

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): > On Thu, 2016-04-14 at 18:56 +0100, Ian Jackson wrote: > > is very unfortunate.  How is a toolstack to know what to do ? > > > Yeah, I agree, but again, I think in this case it

Re: [Xen-devel] [PATCH 2/3] xen: hypercall docs annotations for xen_sysctl_cpupool_op

Dario Faggioli writes ("Re: [PATCH 2/3] xen: hypercall docs annotations for xen_sysctl_cpupool_op"): > On Thu, 2016-04-14 at 18:07 +0100, Ian Jackson wrote: > > Signed-off-by: Ian Jackson > > CC: Jan Beulich > > CC: Tim Deegan > > > Reviewed-by: Dario Faggioli > > One thing, out of curiosity.

[Xen-devel] [PATCH] Config.mk: update mini-os changeset

Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan Please pull from git://xenbits.xen.org/people/liuw/mini-os.git wip.for-xen-unstable before applying this patch. This branch contains important bug fixes that should be in xen 4.7 release. --- Confi

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

On 04/15/16 12:02, Razvan Cojocaru wrote: > +else if ( (msr >= 0x8000) && (msr <= 0x80001fff) ) > +{ > +msr &= 0x1fff; > +__set_bit(msr, &d->arch.monitor_msr_bitmap->high); > +} This of course should be 0xc000 and 0xc0001fff. Sorry for the typo. Will fix it in V

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

On 15/04/16 12:20, Ian Jackson wrote: > Dario Faggioli writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document > XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"): >> On Thu, 2016-04-14 at 18:56 +0100, Ian Jackson wrote: >>> is very unfortunate. How is a toolstack to know what to do ? >>> >> Yeah,

Re: [Xen-devel] [PATCH] Config.mk: update mini-os changeset

Wei Liu writes ("[PATCH] Config.mk: update mini-os changeset"): > Signed-off-by: Wei Liu ... > Please pull from > git://xenbits.xen.org/people/liuw/mini-os.git wip.for-xen-unstable > before applying this patch. Done. And: Acked-by: Ian Jackson > This branch contains important bug fixes that

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

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 > > commit > > my version and you can edit it in-t

Re: [Xen-devel] [PATCH] Config.mk: update mini-os changeset

On Fri, Apr 15, 2016 at 11:57:23AM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH] Config.mk: update mini-os changeset"): > > Signed-off-by: Wei Liu > ... > > Please pull from > > git://xenbits.xen.org/people/liuw/mini-os.git wip.for-xen-unstable > > before applying this patch. > > Done.

Re: [Xen-devel] [PATCH for-4.7] libxl/save: set domain_suspend_state->domid in do_domain_soft_reset()

Wei Liu writes ("Re: [PATCH for-4.7] libxl/save: set domain_suspend_state->domid in do_domain_soft_reset()"): > On Mon, Apr 11, 2016 at 01:36:14PM +0100, Wei Liu wrote: > > Sorry for breaking it! > > > > On Mon, Apr 11, 2016 at 02:20:04PM +0200, Vitaly Kuznetsov wrote: > > > c/s d5c693d "libxl/sa

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 x86, but other arches > >

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 mailing list Xen-devel@list

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] 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 consequences from the mistak

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 >>> com

[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 test-amd64

[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/arch/x86/boot/build32.mk |2 +- 1 file cha

[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" for alloc_mem() bytes argument (suggest

[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 li

[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 %esp,%ebp/leav

[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 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 --- v3

[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 Rzeszutek Wilk), - improve se

[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 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 e.g.

[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 Reviewed-by: Konrad Rzeszutek

[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 p

[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 and

[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 calculate

[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 con

[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: - reorder reloc() arguments

[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 Reviewed-by: Ko

[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

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 can

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 "\xf\x31

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 >>> com

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 fo

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 b

[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 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. Ho

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 exc

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 K

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 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] 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 Xen-4.6.0, and my CPU

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. I

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 directory: > 'iqn=iqn.198

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 pygrub of: >> OSErro

[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] [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] [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: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 a

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 rea

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 serial console shows like this: > > > > domain_crash

[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. Addition

[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 4596d20..82a2a3e 100644 --- a/xen/include/public/sysctl

[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 opera

[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 orde

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 signing up for? >> >>

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. >

[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 guest-start/debian

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 capa

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 situations

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 modi

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 t

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 modi

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 in as soon as the actual hypervisor code side has the appropriate ack. B

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() fo

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: Daniel Kiper Revi

  1   2   >