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
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))
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
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
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
> >
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 &=
>>> 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
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
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
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
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
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
>>> 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
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
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
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
>>> 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
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
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
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
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
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
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
... 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
>>> 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,
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.
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
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(
> >
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
>>> 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
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
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 +
... 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
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 ++
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
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
... 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
... 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
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
... 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
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
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
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
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
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
>>> 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
>>> 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
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
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
... 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
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
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
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
> >> > +++
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
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
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.
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
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
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
>
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
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
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
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,
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
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
>
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
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
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
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
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?
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
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
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
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
>
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
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
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
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
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
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
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
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
>
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
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
101 - 184 of 184 matches
Mail list logo