[Xen-devel] Make the Wiki 4.6 ready: Xen Project Document Day is Wednesday

OUR THEME OF THE MONTH: "Ready for 4.6" This month, we continue with the effort to make the Wiki reflect the realities of the 4.6 release. Many pages need reviewing and may need updating. Main tasks include: - Add new documentation for new features - Modify existing documentation for anything

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

On Mon, Oct 26, 2015 at 01:52:47PM +0100, Samuel Thibault wrote: > Wei Liu, le Mon 26 Oct 2015 12:47:56 +, a écrit : > > -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < > > sizeof(msg)) > > +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < > > sizeof(msg))

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

On Mon, Oct 26, 2015 at 01:21:46PM +, Ross Lagerwall wrote: > On 10/26/2015 12:01 PM, Martin Pohlack wrote: > >On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote: > > > >[...] > > > >>+### xsplice_patch > >>+ > >>+This structure has the binary code (or data) to be patched. Depending on > >>the

[Xen-devel] (XEN) Fatal machine check

Hi, i'm getting this problem with linux 4.3.0-rcX branch. Full log is attached. My hardware is based on intel skylake i7-6700k on z170 chipset and it is working properly. It does boot correctly with older kernels (3.12). With mce=off on xen parameters it does boot unti during pci detection where

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

On Mon, Oct 26, 2015 at 01:02:45PM +0100, Samuel Thibault wrote: > Hello, > > Indeed, notification seems to have been missing since basically 2006... > > Wei Liu, le Mon 26 Oct 2015 09:47:48 +, a écrit : > > diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c > > index 4613ed6..7451161 100644 > >

Re: [Xen-devel] [PATCH 1/2] xen/x86: Helpers for cpu feature manipuation

On 26/10/15 12:06, Jan Beulich wrote: On 26.10.15 at 12:17, wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -202,7 +202,7 @@ static void __init early_cpu_detect(void) >> c->x86_mask = tfms & 15; >> cap0 &=

Re: [Xen-devel] [V8 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen

>>> On 23.10.15 at 11:48, wrote: > This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor > to perform the xsave_area switching so that xen itself > can benefit from them when available. > > For xsaves/xrstors/xsavec only use compact format. Add format

Re: [Xen-devel] ovmf fails to build in stagin-4.6

On Mon, Oct 26, 2015 at 12:13:40PM +0100, Olaf Hering wrote: > On Mon, Oct 26, Wei Liu wrote: > > > Wait, so you're using gcc-5.1.1 but OVMF is reporting gcc-4.4 (see in > > the path of output string), there might be another problem with > > toolchain detection then. > > As Linus said: detect

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

Wei Liu, le Mon 26 Oct 2015 12:30:28 +, a écrit : > On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote: > > Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit : > > > In my patch, mini-os notifies remote whenever it consumes a message, > > > which I think it's slightly better

[Xen-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

The xenbus thread didn't send notification to other end when it expected more data or consumed responses, which led to stalling the ring from time to time. This is the culprit that guest was less responsive when using stubdom because the device model was stalled. Fix this by sending notification

Re: [Xen-devel] [PATCH v2 4/5] x86/mm: build map_domain_gfn() just once

On 26/10/15 11:52, Jan Beulich wrote: > It doesn't depend on GUEST_PAGING_LEVELS. Moving the function to p2m.c > at once allows a bogus #define/#include pair to be removed from > hap/nested_ept.c. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

On 10/26/2015 12:01 PM, Martin Pohlack wrote: On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote: [...] +### xsplice_patch + +This structure has the binary code (or data) to be patched. Depending on the +type it can either an inline patch (data or text) or require an relocation +change (which

Re: [Xen-devel] [PATCH v1 1/5] xsplice: Design document.

>>> On 26.10.15 at 13:01, wrote: > On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote: >> +The convention for file-type symbols (that would allow to map many >> +symbols to their compilation unit) says that only the basename (i.e., >> +without directories) is embedded. This

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

Hello, Indeed, notification seems to have been missing since basically 2006... Wei Liu, le Mon 26 Oct 2015 09:47:48 +, a écrit : > diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c > index 4613ed6..7451161 100644 > --- a/xenbus/xenbus.c > +++ b/xenbus/xenbus.c > @@ -205,8 +205,10 @@ static void

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit : > In my patch, mini-os notifies remote whenever it consumes a message, > which I think it's slightly better because backend can start putting > things in the ring as mini-os processes them. That makes more notifications, but that can lead to

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

On Mon, Oct 26, 2015 at 01:21:51PM +0100, Samuel Thibault wrote: > Wei Liu, le Mon 26 Oct 2015 12:14:43 +, a écrit : > > In my patch, mini-os notifies remote whenever it consumes a message, > > which I think it's slightly better because backend can start putting > > things in the ring as

Re: [Xen-devel] [V8 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

>>> On 23.10.15 at 11:48, wrote: > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -23,8 +23,8 @@ static u32 __read_mostly xsave_cntxt_size; > > /* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */ > u64 __read_mostly

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()"): > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote: > > Tools maintainers, could I please get an ack or otherwise on this > > adjustment? I confess I'm out of my depth

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

On 26/10/15 15:08, Jan Beulich wrote: On 26.10.15 at 15:58, wrote: >> On 26/10/15 14:55, Andrew Cooper wrote: >>> On 26/10/15 14:43, David Vrabel wrote: On 23/09/15 16:34, Jan Beulich wrote: > Us extending the GDT limit past the Xen descriptors so far

[Xen-devel] [linux-3.14 test] 63309: regressions - trouble: blocked/broken/fail/pass

flight 63309 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63309/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 kernel-build fail REGR. vs. 62648 Tests which are

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()"): > I was assuming some random third party tools make use of > xc_shadow_control just to get the dirty bitmap of the guest. > > I don't have concrete examples at hand though. Maybe

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

On Mon, Oct 26, 2015 at 03:52:55PM +, Ian Jackson wrote: > Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty > marking in hvm_map_guest_frame_rw()"): > > I was assuming some random third party tools make use of > > xc_shadow_control just to get the dirty bitmap of

[Xen-devel] [RFC PATCH v2 05/16] libxl: Load guest BIOS from file

The path to the BIOS blob can be override by the xl's bios_override option, or provided by u.hvm.bios_filename in the domain_build_info struct by other libxl user. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_dom.c | 66

[Xen-devel] [RFC PATCH v2 10/16] hvmloader: Load OVMF from modules

... and do not include the OVMF ROM into hvmloader anymore. Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/ovmf.c | 22 +++--- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/tools/firmware/hvmloader/ovmf.c

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

>>> On 26.10.15 at 17:05, wrote: > On Mon, Oct 26, 2015 at 10:00:26AM -0600, Jan Beulich wrote: >> >>> On 26.10.15 at 16:20, wrote: >> > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote: >> >> >>> On 19.10.15 at 16:53,

[Xen-devel] [xen-unstable-smoke test] 63320: trouble: broken/pass

flight 63320 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/63320/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 3 host-install(3) broken REGR.

[Xen-devel] [qemu-mainline baseline-only test] 38213: tolerable FAIL

This run is configured for baseline tests only. flight 38213 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38213/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-xsm 21

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote: > >>> On 19.10.15 at 16:53, wrote: > > --- a/tools/libxc/xc_sr_save.c > > +++ b/tools/libxc/xc_sr_save.c > > @@ -537,7 +537,8 @@ static int suspend_and_send_dirty(struct > > if ( xc_shadow_control( > >

Re: [Xen-devel] Ping: [PATCH] use clear_domain_page() instead of open coding it

Jan Beulich writes ("Ping: [PATCH] use clear_domain_page() instead of open coding it"): > "REST" maintainers, could I please get an ack or otherwise on this > common code change? I'm not qualified to review this, but I would have thought an ack from George should be sufficient ? (Also is your

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

>>> On 26.10.15 at 16:20, wrote: > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote: >> >>> On 19.10.15 at 16:53, wrote: >> > --- a/tools/libxc/xc_sr_save.c >> > +++ b/tools/libxc/xc_sr_save.c >> > @@ -537,7 +537,8 @@ static int

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

On 26/10/15 15:58, Jan Beulich wrote: On 26.10.15 at 16:41, wrote: >> Apply this partial revert fixes the problem for me. > > This would need some cleaning up, but I could do that. May I put your > S-o-b underneath it (with or without the extra cleanup)? If you

[Xen-devel] [RFC PATCH v2 06/16] libxl: Load guest ACPI table from file

The path to the ACPI tables blob can be override by xl's option acpi_table_override or by acpi_tables_filename in the domain_build_info struct for libxl user. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_dom.c | 17 +

[Xen-devel] [RFC PATCH v2 12/16] hvmloader: Load ACPI tables from hvm_start_info module

... and use it with both SeaBIOS and OVMF. This may change the behavior of guest using OVMF as the ACPI tables currently loaded are the one for qemu-xen-traditionnal. After this change, the ACPI tables will the one intended for the device model used. Signed-off-by: Anthony PERARD

[Xen-devel] [RFC PATCH v2 03/16] configure: #define SEABIOS_PATH and OVMF_PATH

Those paths are to be used by libxl, in order to load the firmware in memory. If a system path is not define, then this default to the Xen firmware directory. Signed-off-by: Anthony PERARD --- Please, run ./autogen.sh on this patch. --- tools/configure.ac | 6 ++

[Xen-devel] [RFC PATCH v2 13/16] hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob

Those are not used anymore by hvmloader. Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/Makefile | 26 -- 1 file changed, 26 deletions(-) diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile index

[Xen-devel] [RFC PATCH v2 14/16] hvmloader: Always build-in SeaBIOS and OVMF loader

Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/Makefile| 6 -- tools/firmware/hvmloader/hvmloader.c | 4 2 files changed, 10 deletions(-) diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile index

[Xen-devel] [RFC PATCH v2 04/16] firmware/makefile: install BIOS and ACPI blob ...

... into the firmware directory, along with hvmloader. Signed-off-by: Anthony PERARD --- .gitignore | 1 + tools/firmware/Makefile| 15 +++ tools/firmware/hvmloader/acpi/Makefile | 2 +- 3 files changed, 17

[Xen-devel] [RFC PATCH v2 02/16] libxc: Load BIOS and ACPI table into guest memory

... and prepare a cmdline for hvmloader with the order of the modules. Signed-off-by: Anthony PERARD --- tools/libxc/include/xc_dom.h | 4 ++ tools/libxc/xc_dom_hvmloader.c | 44 + tools/libxc/xc_dom_x86.c | 90

[Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

Hi all, I've start to look at loading the BIOS and the ACPI tables via the toolstack instead of having them embedded in the hvmloader binary. After this patch series, hvmloader compilation would be indenpendant from SeaBIOS and OVMF compilation. Compare to the V1, this is now done via the struct

[Xen-devel] [RFC PATCH v2 09/16] hvmloader: Load SeaBIOS from hvm_start_info modules ...

... and do not include the SeaBIOS ROM into hvmloader anymore. Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/seabios.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/tools/firmware/hvmloader/seabios.c

[Xen-devel] [RFC PATCH v2 08/16] hvmloader: Locate the BIOS blob

The BIOS can be found in one of the entry of the modlist of the hvm_start_info struct. The order of the modules are define by the command line option "modules". The found BIOS blob is not loaded by this patch, but only passed as argument to bios_load() function. It is going to be used by the next

[Xen-devel] [RFC PATCH v2 07/16] hvmloader: Grab the hvmlite info page and parse the cmdline

Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/hvmloader.c | 69 +++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c index

[Xen-devel] [RFC PATCH v2 15/16] hvmloader: Compile out the qemu-xen ACPI tables

It should now be loaded by libxl. Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/acpi/Makefile | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/firmware/hvmloader/acpi/Makefile b/tools/firmware/hvmloader/acpi/Makefile index

Re: [Xen-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

Wei Liu writes ("[PATCH MINI-OS v2] xenbus: notify the other end when necessary"): > The xenbus thread didn't send notification to other end when it expected > more data or consumed responses, which led to stalling the ring from > time to time. Thanks for investigating this. I haven't attempted

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

On Mon, Oct 26, 2015 at 03:42:07PM +, Ian Jackson wrote: > Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty > marking in hvm_map_guest_frame_rw()"): > > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote: > > > Tools maintainers, could I please get an ack

Re: [Xen-devel] [PATCH] x86/PV: properly populate descriptor tables

>>> On 26.10.15 at 16:41, wrote: > Apply this partial revert fixes the problem for me. This would need some cleaning up, but I could do that. May I put your S-o-b underneath it (with or without the extra cleanup)? Jan > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c

Re: [Xen-devel] Ping: [PATCH] use clear_domain_page() instead of open coding it

>>> On 26.10.15 at 16:47, wrote: > Jan Beulich writes ("Ping: [PATCH] use clear_domain_page() instead of open > coding it"): >> "REST" maintainers, could I please get an ack or otherwise on this >> common code change? > > I'm not qualified to review this, but I would

[Xen-devel] [RFC PATCH v2 01/16] hvmloader: Fix scratch_alloc to avoid overlaps

scratch_alloc() set scratch_start to the last byte of the current allocation. The value of scratch_start is then reused as is (if it is already aligned) in the next allocation. This result in a potential reuse of the last byte of the previous allocation. Signed-off-by: Anthony PERARD

[Xen-devel] [RFC PATCH v2 11/16] hvmloader: No BIOS ROM image allowed to be compiled in

Signed-off-by: Anthony PERARD --- tools/firmware/hvmloader/config.h| 7 --- tools/firmware/hvmloader/hvmloader.c | 16 2 files changed, 4 insertions(+), 19 deletions(-) diff --git a/tools/firmware/hvmloader/config.h

[Xen-devel] [RFC PATCH v2 16/16] hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH ...

... to compile SeaBIOS and OVMF. Only depends on CONFIG_*. If --with-system-* configure option is used, then set *_CONFIG=n to not compile SEABIOS and OVMF. Signed-off-by: Anthony PERARD --- Please, run ./autogen.sh on this patch. --- tools/configure.ac | 6

Re: [Xen-devel] RFC: Survey on release cycle

Wei Liu writes ("[Xen-devel] RFC: Survey on release cycle"): > Please express your preference with -2 (strongly argue against), -1 > (not happy but not against), +1 (happy but won't argue for) and +2 > (happy and argue for). > > # 6 months release cycle + current stable release scheme > > The

Re: [Xen-devel] RFC: Survey on release cycle

Ian Campbell writes ("Re: [Xen-devel] RFC: Survey on release cycle"): > On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > > The same stable release scheme applies (18 months full support + 18 > > months security fixes). Encourage more people to step up to share the > > maintenance burden if

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

On Mon, Oct 26, 2015 at 10:00:26AM -0600, Jan Beulich wrote: > >>> On 26.10.15 at 16:20, wrote: > > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan Beulich wrote: > >> >>> On 19.10.15 at 16:53, wrote: > >> > --- a/tools/libxc/xc_sr_save.c > >> > +++

[Xen-devel] [PATCH] x86/PV: don't zero-map LDT

This effectvely reverts the LDT related part of commit cf6d39f819 ("x86/PV: properly populate descriptor tables"), which broke demand paged LDT handling in guests. Reported-by: David Vrabel Diagnosed-by: Andrew Cooper Signed-off-by: Jan

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

On Mon, Oct 26, 2015 at 10:15:13AM -0600, Jan Beulich wrote: > >>> On 26.10.15 at 17:05, wrote: > > On Mon, Oct 26, 2015 at 10:00:26AM -0600, Jan Beulich wrote: > >> >>> On 26.10.15 at 16:20, wrote: > >> > On Mon, Oct 26, 2015 at 07:09:06AM -0600, Jan

Re: [Xen-devel] [PATCH v2 5/5] xl: improve return and exit codes of parse related functions

On Sat, Oct 24, 2015 at 11:01:36AM +0530, Harmandeep Kaur wrote: > turning parsing related functions xl exit codes towards using the > EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers They are constants, not macros -- I'm a being pedantic here. :-) > or libxl return codes.

[Xen-devel] Cannot boot into Dom0 after reading vcpu_info in sched_credit

Hi there I need to access event channel mask and pending bits for a vcpu in sched_credit.c. Thus I'm trying to get and print this info in runq_insert using vcpu_info like this: printk("\nhello %d %d \n",vcpu_info(svc->vcpu,evtchn_upcall_mask),vcpu_info(svc->vcpu,evtchn_upcall_pending)); After

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

flight 63322 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/63322/ 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 v2 1/5] xl: convert exit codes to EXIT_[SUCCESS|FAILURE]

On Sat, Oct 24, 2015 at 11:01:32AM +0530, Harmandeep Kaur wrote: > turning main function xl exit codes towards using the > EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers > or libxl return codes. > > also includes a document comment in xl.h stating xl process should >

Re: [Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

On Fri, Oct 23, 2015 at 03:04:59PM +0200, Juergen Gross wrote: > This series is a combination of my previous patches: > > "libxc: remove most of tools/libxc/xc_dom_compat_linux.c" > "tools: remove unused wrappers for python" > > I have split it up as requested by Ian Campbell, thus it consists

Re: [Xen-devel] [PATCH] x86/PV: don't zero-map LDT

On 26/10/15 16:14, Jan Beulich wrote: > This effectvely reverts the LDT related part of commit cf6d39f819 > ("x86/PV: properly populate descriptor tables"), which broke demand > paged LDT handling in guests. > > Reported-by: David Vrabel > Diagnosed-by: Andrew Cooper

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

On Mon, Oct 26, 2015 at 05:37:51PM +0100, Samuel Thibault wrote: > Ian Jackson, le Mon 26 Oct 2015 16:32:10 +, a écrit : > > Samuel Thibault writes ("Re: [Minios-devel] [PATCH MINI-OS v2] xenbus: > > notify the other end when necessary"): > > > Ok... This is still very worrying. The more

Re: [Xen-devel] [PATCH net-next 3/8] xen-netback: support multiple extra info segments passed from frontend

On Wed, Oct 21, 2015 at 11:36:20AM +0100, Paul Durrant wrote: > The code does not currently allow a frontend to pass multiple extra info > segments to the backend in a tx request. A subsequent patch in this series > needs this functionality so it is added here, without any other > modification,

Re: [Xen-devel] [PATCH net-next 8/8] xen-netback: add support for toeplitz hashing

On Wed, Oct 21, 2015 at 11:36:25AM +0100, Paul Durrant wrote: > This patch adds all the necessary infrastructure to allow a frontend to > specify toeplitz hashing of network packets on its receive side. (See > netif.h for details of the xenbus protocol). > > The toeplitz hash algorithm itself was

Re: [Xen-devel] [PATCH net-next 1/8] xen-netback: re-import canonical netif header

On Wed, Oct 21, 2015 at 11:36:18AM +0100, Paul Durrant wrote: > The canonical netif header (in the Xen source repo) and the Linux variant > have diverged significantly. Recently much documentation has been added to > the canonical header and new definitions and types to support packet hash >

Re: [Xen-devel] [PATCH net-next 6/8] xen-netback: pass an L4 or L3 skb hash value to the frontend

On Wed, Oct 21, 2015 at 11:36:23AM +0100, Paul Durrant wrote: > If the frontend indicates it's capable (see netif.h for details) and an > skb has an L4 or L3 hash value then pass the value to the frontend in > a xen_netif_extra_info segment. > > Signed-off-by: Paul Durrant

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

Wei Liu, le Mon 26 Oct 2015 16:41:15 +, a écrit : > The oxenstored in staging. Ok. For a first, one fishy thing at quick sight is that the only occurence of rsp_cons (except at closure) is when writing, and not when going to sleep. One issue there is that ml_interface_write only writes a

Re: [Xen-devel] [PATCH v2 3/5] x86/mm: override stored file names for multiply built sources

On 26/10/15 11:51, Jan Beulich wrote: > To make it possible to tell apart the static symbols therein, use their > object file names instead of their source ones. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap > --- > v2: Introduce

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

Wei Liu, le Mon 26 Oct 2015 13:55:31 +, a écrit : > On Mon, Oct 26, 2015 at 01:52:47PM +0100, Samuel Thibault wrote: > > Wei Liu, le Mon 26 Oct 2015 12:47:56 +, a écrit : > > > -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons < > > > sizeof(msg)) > > > +if

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

Samuel Thibault writes ("Re: [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary"): > Ok... This is still very worrying. The more I'm thinking about it, > the more I believe we shouldn't *have* to do this. Which version of > the xenstore are you testing with, exactly?

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

On Mon, Oct 26, 2015 at 05:43:53PM +0100, Samuel Thibault wrote: > Also, just to make sure: you tested with the third and fourth hooks of > your v2 patch applied, only first and second hooks were removed? > > Samuel See the patch below. >From 0643a821ce2795e7e65e199e7caaa657f27bafcf Mon Sep 17

Re: [Xen-devel] [PATCH net-next 7/8] xen-netback: add support for a multi-queue hash mapping table

On Wed, Oct 21, 2015 at 11:36:24AM +0100, Paul Durrant wrote: > Advertise the capability to handle a hash mapping specified by the > frontend (see netif.h for details). > > Add an ndo_select() entry point so that, of the frontend does specify a "if the frontend ..." > hash mapping, the skb hash

Re: [Xen-devel] [PATCH net-next 4/8] xen-netback: accept an L4 or L3 skb hash value from the frontend

On Wed, Oct 21, 2015 at 11:36:21AM +0100, Paul Durrant wrote: > This patch adds an indication that netback is capable of handling hash > values passed from the frontend (see netif.h for details), and the code > necessary to process the additional xen_netif_extra_info segment and > set a hash on

Re: [Xen-devel] [PATCH net-next 2/8] xen-netback: remove GSO information from xenvif_rx_meta

On Wed, Oct 21, 2015 at 11:36:19AM +0100, Paul Durrant wrote: > The code in net_rx_action() that builds rx responses has direct access > to the skb so there is no need to copy this information into the meta > structure. > > This patch removes the extraneous fields, saves space in the array and >

Re: [Xen-devel] [PATCH] tools: create XEN_DUMP_DIR with mode 0700

On Thu, Oct 22, 2015 at 05:32:57PM +0100, Ian Campbell wrote: > On Wed, 2015-10-21 at 15:15 +0100, Wei Liu wrote: > > That directory is used to store guest memory dump which contains > > sensitive information. > > > > Signed-off-by: Wei Liu > > Acked-by: Ian Campbell

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

Hu, Robert writes ("RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'"): > > From: Hu, Robert ... > > Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall > > be > > hvc0 in nested environment. > [Hu, Robert] Thanks for the update. I'm

Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()"): > On Mon, Oct 26, 2015 at 03:52:55PM +, Ian Jackson wrote: > > Wei Liu writes ("Re: [Xen-devel] Ping: [PATCH v3] x86/HVM: correct page > > dirty marking in

Re: [Xen-devel] (XEN) Fatal machine check

On Mon, Oct 26, 2015 at 01:04:03PM +0100, John Doe wrote: > Hi, i'm getting this problem with linux 4.3.0-rcX branch. > Full log is attached. My hardware is based on intel skylake i7-6700k on > z170 chipset and it is working properly. It does boot correctly with > older kernels (3.12). > With

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

Ian Jackson, le Mon 26 Oct 2015 16:32:10 +, a écrit : > Samuel Thibault writes ("Re: [Minios-devel] [PATCH MINI-OS v2] xenbus: notify > the other end when necessary"): > > Ok... This is still very worrying. The more I'm thinking about it, > > the more I believe we shouldn't *have* to do

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

Also, just to make sure: you tested with the third and fourth hooks of your v2 patch applied, only first and second hooks were removed? Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] xSplice prototype

On 10/26/2015 03:03 PM, Konrad Rzeszutek Wilk wrote: On Mon, Oct 26, 2015 at 08:35:30AM +, Ross Lagerwall wrote: It was added as a way to do signature checking and any other type of checking that needed to be done. And which may take quite a while to get done - hence doing it

Re: [Xen-devel] [Minios-devel] [PATCH MINI-OS v2] xenbus: notify the other end when necessary

On Mon, Oct 26, 2015 at 06:11:04PM +0100, Samuel Thibault wrote: > Wei Liu, le Mon 26 Oct 2015 16:41:15 +, a écrit : > > The oxenstored in staging. > > Ok. For a first, one fishy thing at quick sight is that the only > occurence of rsp_cons (except at closure) is when writing, and not when >

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

Hi, On 23/10/15 15:55, Ian Campbell wrote: > On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote: >> On 23/10/15 15:37, Jan Beulich wrote: >> On 23.10.15 at 16:31, wrote: On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote: > No, the validating script is

Re: [Xen-devel] Cannot boot into Dom0 after reading vcpu_info in sched_credit

On Mon, 2015-10-26 at 17:28 +, amin.fall...@gmail.com wrote: > The same printk works without any problem when I use it in > event_channel.c to print those info. > So there are a few questions: > 1. Any idea what is the reason of reboot and how to fix it? > 2. Any idea how can I examine logs

<    1   2