On Fri, Dec 09, 2016 at 06:03:06PM +, Julien Grall wrote:
> Hi Daniel,
>
> On 05/12/16 22:25, Daniel Kiper wrote:
> >There is a problem with place_string() which is used as early memory
> >allocator. It gets memory chunks starting from start symbol and goes
> >down. Sadly this does not work whe
When relocating the p2m, take special care not to relocate it so
that is overlaps with the current location of the p2m/initrd. This is
needed since the full extent of the current location is not marked as a
reserved region in the e820.
This was seen to happen to a dom0 with a large initial p2m and
flight 103201 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103201/
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 1
On Mon, Dec 12, 2016 at 04:38:38PM +0800, Haozhong Zhang wrote:
> On 12/12/16 01:30 -0700, Jan Beulich wrote:
> > > > > On 12.12.16 at 05:16, wrote:
> > > On 12/09/16 17:02 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Oct 10, 2016 at 08:32:22AM +0800, Haozhong Zhang wrote:
> > > > > +static
Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry
on constraint violation"):
> If I recall correctly, the constraints for which there can be
> errors appearing due to concurrent transactions are primary key,
> unique, and foreign key constraints. I don't remember seei
>>> On 05.12.16 at 20:36, wrote:
> +unsigned int ioapic_id_to_index(unsigned int apic_id)
> +{
> +unsigned int idx;
> +
> +if ( !nr_ioapic_sbdf )
> +return MAX_IO_APICS;
This is pointless (redundant with ...
> +for ( idx = 0 ; idx < nr_ioapic_sbdf; idx++ )
> +if ( ioa
On Tue, Nov 22, 2016 at 03:09:14PM +, Andre Przywara wrote:
> From: Christoffer Dall
>
> Add support for building a Xen binary which includes a Dom0 image and
> the Dom0 command-line.
>
> If the user specifies --with-xen=, where Xen is an appropriate
> AArch64 Xen binary, the build system wi
On Tue, Nov 22, 2016 at 03:09:15PM +, Andre Przywara wrote:
> From: Christoffer Dall
>
> Support adding xen,xen-bootargs node via --with-xen-bootargs to the
> configure script and automatically add the Dom0 node to the DT as well.
>
> Signed-off-by: Christoffer Dall
> Signed-off-by: Andre P
On Tue, Nov 22, 2016 at 03:09:17PM +, Andre Przywara wrote:
> From: Christoffer Dall
>
> When doing a make clean, only the output image currently configured to
> build is being removed. However, one would expect all build artifacts
> to be removed when doing a 'make clean' and when switching
On Tue, Nov 22, 2016 at 03:09:16PM +, Andre Przywara wrote:
> From: Ian Campbell
>
> If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
> the usual ttyAMA0 otherwise.
>
> Signed-off-by: Ian Campbell
> Signed-off-by: Christoffer Dall
> Signed-off-by: Andre Przywara
>
On Mon, Dec 12, 2016 at 12:56:32PM +0530, George John wrote:
> hi,
>
> Thanks for the reply. I want to bring up xen on an intel embedded
> development platform. I am going to buy one. Can you suggest a intel
> development platform for embedded applications on which xen could work?
Um, your lapto
At 13:05 + on 12 Dec (1481547944), Andrew Cooper wrote:
> On 12/12/16 11:57, Tim Deegan wrote:
> > At 11:45 + on 12 Dec (1481543145), Andrew Cooper wrote:
> >> On 12/12/16 11:27, Tim Deegan wrote:
> >>> At 10:43 + on 12 Dec (1481539421), Andrew Cooper wrote:
> PV guests necessarily
When pruning entries from the fixup table, update the offsets in
.rela.ex_table otherwise the relas might point to the wrong fixup entry
or even out of the .fixup section.
This is a port of kpatch's commit 13d61012f9b2 ("create-diff-object:
Update fixup offsets in .rela__ex_table").
Signed-off-by
Hi Konrad,
On 12/12/16 14:47, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 22, 2016 at 03:09:17PM +, Andre Przywara wrote:
>> From: Christoffer Dall
>>
>> When doing a make clean, only the output image currently configured to
>> build is being removed. However, one would expect all build artif
GCC 6.1+ fixed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192 which
means that .rodata.str1.[0-9]+ sections are now split by function. We
could probably be smarter about including just the sections we need, but
for now, simply include the string sections for all functions as is done
for previous
On Mon, Dec 12, 2016 at 02:52:34PM +, Ross Lagerwall wrote:
> When pruning entries from the fixup table, update the offsets in
> .rela.ex_table otherwise the relas might point to the wrong fixup entry
> or even out of the .fixup section.
>
> This is a port of kpatch's commit 13d61012f9b2 ("cre
On Mon, Dec 12, 2016 at 02:55:51PM +, Ross Lagerwall wrote:
> GCC 6.1+ fixed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192 which
> means that .rodata.str1.[0-9]+ sections are now split by function. We
> could probably be smarter about including just the sections we need, but
> for now, simp
>>> On 09.12.16 at 16:44, wrote:
> Not used yet, so no functional change. We will need this in a moment.
>
> Signed-off-by: Ian Jackson
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 09.12.16 at 16:44, wrote:
> This will allow us to keep track of the total amount of work we are
> doing. When it becomes excessive, we mark the ELF broken, and stop
> processing.
>
> This is a more robust way of preventing DoS problems by bad images
> than attempting to prove, for each of
On 12/12/16 15:35, Ross Lagerwall wrote:
> When relocating the p2m, take special care not to relocate it so
> that is overlaps with the current location of the p2m/initrd. This is
> needed since the full extent of the current location is not marked as a
> reserved region in the e820.
>
> This was
>>> On 09.12.16 at 16:44, wrote:
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -43,10 +43,13 @@ elf_errorstatus elf_xen_parse_features(struct elf_binary
> *elf,
> if ( features == NULL )
> return 0;
>
> -for ( pos = 0; features[pos]
>>> On 09.12.16 at 16:44, wrote:
> @@ -80,7 +81,8 @@ void elf_memcpy_safe(struct elf_binary *elf, elf_ptrval dst,
>
> void elf_memset_safe(struct elf_binary *elf, elf_ptrval dst, int c, size_t
> size)
> {
> -if ( elf_access_ok(elf, dst, size) )
> +if ( elf_access_ok(elf, dst, size) &&
>>> On 09.12.16 at 16:44, wrote:
> +static inline bool elf_iter_ok(struct elf_binary *elf)
> +{ return elf_iter_ok_counted(elf,1); }
Having seen first uses of this - why is this 1 instead of 0? Once it is,
calling elf_iter_ok_counted() here would be rather pointless, and
checking just elf_bro
>>> On 09.12.16 at 16:44, wrote:
> /* other */
> -if ( !strcmp(name, "FEATURES") )
> -if ( elf_xen_parse_features(value, parms->f_supported,
> +if ( !elf_strcmp_safe(elf, name, "FEATURES") )
> +if ( elf_xen_parse_features(elf, value, parms->f_suppor
Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok
and elf_strcmp_safe"):
> On 09.12.16 at 16:44, wrote:
> > This is a more robust way of preventing DoS problems by bad images
> > than attempting to prove, for each of the (sometimes rather deeply
> > nested) loops, th
On 12/12/2016 03:01 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 12, 2016 at 02:55:51PM +, Ross Lagerwall wrote:
GCC 6.1+ fixed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192 which
means that .rodata.str1.[0-9]+ sections are now split by function. We
could probably be smarter about includ
flight 103159 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103159/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
103108
test-amd6
Thanks for your careful review.
Jan Beulich writes ("Re: [PATCH 3/8] libelf: loop safety: Call
elf_iter_ok[_counted] in every loop"):
> On 09.12.16 at 16:44, wrote:
> > +for ( pos = 0;
> > + elf_iter_ok_counted(elf, sizeof(feature)) &&
> > + features[pos] != '\0';
>
>
>>> On 09.12.16 at 16:44, wrote:
> All the loops which might go out of control, due to excessive shdrs,
> have been decorated with elf_iter_ok. So there is no need for this
> explicit (and rather crude) check.
>
> (Anyway, the count was a 16-bit field, so the check was redundant.)
>
> Signed-of
Jan Beulich writes ("Re: [PATCH 5/8] libelf: loop safety: Replace all calls to
strcmp"):
> On 09.12.16 at 16:44, wrote:
> > /* other */
> > -if ( !strcmp(name, "FEATURES") )
> > -if ( elf_xen_parse_features(value, parms->f_supported,
> > +if ( !elf_strcmp_safe
>>> On 09.12.16 at 16:44, wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -38,6 +38,7 @@ elf_errorstatus elf_init(struct elf_binary *elf, const char
> *image_input, size_t
> ELF_HANDLE_DECL(elf_shdr) shdr;
> unsigned i, count, section, lin
On Thu, Nov 17, 2016 at 12:24:20PM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH v1 7/7] make-flight/mfi-common: Add
> them in the matrix."):
> > Signed-off-by: Konrad Rzeszutek Wilk
>
> Can you accompany this with a diff of the output of
>standalone-generate-dump-flight-
Jan Beulich writes ("Re: [PATCH 4/8] libelf: loop safety: Call
elf_iter_ok_counted at every *mem*_unsafe"):
> On 09.12.16 at 16:44, wrote:
> > -if ( elf_access_ok(elf, dst, size) )
> > +if ( elf_access_ok(elf, dst, size) &&
> > + elf_iter_ok_counted(elf, size))
>
> With the style
>>> On 12.12.16 at 16:38, wrote:
>> > @@ -273,11 +276,12 @@ elf_errorstatus elf_xen_parse_guest_info(struct
>> > elf_binary *elf,
>> >
>> > h = parms->guest_info;
>> > #define STAR(h) (elf_access_unsigned(elf, (h), 0, 1))
>> > -while ( STAR(h) )
>> > +while ( elf_iter_ok_counted(e
>>> On 12.12.16 at 16:54, wrote:
> Jan Beulich writes ("Re: [PATCH 4/8] libelf: loop safety: Call
> elf_iter_ok_counted at every *mem*_unsafe"):
>> On 09.12.16 at 16:44, wrote:
>> > -if ( elf_access_ok(elf, dst, size) )
>> > +if ( elf_access_ok(elf, dst, size) &&
>> > + elf_iter_
Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a
default ioreq server") breaks restore for HVM guests.
I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok
and elf_strcmp_safe"):
> On 09.12.16 at 16:44, wrote:
> > +const uint64_t max_size_for_deacc = (1UL <<
> > 63)/ELF_MAX_ITERATION_FACTOR;
...
> > +elf->iteration_deaccumulator = 1024*1024 +
> > +(size
Jan Beulich writes ("Re: [PATCH 3/8] libelf: loop safety: Call
elf_iter_ok[_counted] in every loop"):
> On 12.12.16 at 16:38, wrote:
> > So the calls to elf_memset_unchecked, to zero name and value, imply
> > that there must be a call to elf_iter_ok_counted. The count parameter
> > should be the
Jan Beulich writes ("Re: [PATCH 4/8] libelf: loop safety: Call
elf_iter_ok_counted at every *mem*_unsafe"):
> On 12.12.16 at 16:54, wrote:
> > I have added the missing space, and also moved the && to the next
> > line (as seems to be done in much of the hypervisor).
> >
> > I hope that meets wit
Update the structure of the FADT table to version 5, and use that version for
PVHv2 guests. Note that HVM guests will continue to use FADT 4. In order to do
this, add a new field to acpi_config that contains the ACPI revision to use by
libacpi. Note that currently this only applies to the FADT.
Si
At the moment this flag is unconditionally set for PVHv2 domains. Note that
using this boot flag requires that the FADT table revision is at least 5 (or any
later version), so bump the current FADT version from 4 to 5 and add two new
fields that will be unused.
Reported-by: Jan Beulich
Signed-off
Hello,
Those are the remaining two patches in the series, the first one adds supports
for FADT v5 to libacpi, and the second one introduces the usage of the FADT no
RTC boot flag for PVHv2 guests. Note that ACPI tables for HVM guests should
remain unmodified.
_
The path to the xenstore FreeBSD device is /dev/xen/xenstore.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/xenstore/xs_lib.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 5ef3d6d..3e43f88 100644
--- a/t
On 12/12/2016 08:28 AM, Julien Grall wrote:
> Hi Boris,
>
> On 29/11/16 15:33, Boris Ostrovsky wrote:
>> This domctl will allow toolstack to read and write some
>> ACPI registers. It will be available to both x86 and ARM
>> but will be implemented first only for x86
>
> Can you explain why we would
>>> On 12.12.16 at 17:00, wrote:
> Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce
> elf_iter_ok and elf_strcmp_safe"):
>> On 09.12.16 at 16:44, wrote:
>> > +const uint64_t max_size_for_deacc = (1UL <<
>> > 63)/ELF_MAX_ITERATION_FACTOR;
> ...
>> > +elf->iteration_dea
On 12/12/2016 09:02 AM, Jan Beulich wrote:
On 12.12.16 at 14:08, wrote:
>> On 12/02/2016 02:48 AM, Jan Beulich wrote:
>> On 01.12.16 at 17:43, wrote:
On 12/01/2016 11:06 AM, Jan Beulich wrote:
>> +++ b/xen/include/public/domctl.h
>> @@ -1144,6 +1144,29 @@ struct xen_domctl_p
>>> On 12.12.16 at 17:01, wrote:
> Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a
> default ioreq server") breaks restore for HVM guests.
>
> I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log.
And that's qemu-trad or qemu-upstream?
Jan
__
The default timeout in the hypervisor for a livepatch operation is 30 ms,
but xen-livepatch currently waits for up to 30 seconds for the operation
to complete. Instead, remove the retry loop and simply wait for 2 * 30 ms
for the operation to complete. The extra period is to account for the
time to
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 5/7] ts-livepatch:
Initial test-cases."):
> Let me answer only to some as I am fixing the rest per your comments:
>
> On Thu, Nov 17, 2016 at 12:21:58PM +, Ian Jackson wrote:
> > Is it ever possible to continue with the rest of the live
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 3/7] ts-xen-build:
Install livepatch regressions tests. [and 1 more messages]"):
> On Thu, Nov 17, 2016 at 11:49:19AM +, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("[PATCH v1 3/7] ts-xen-build: Install
> > livepatch regression
On Tue, Nov 08, 2016 at 12:18:05PM +0100, Juergen Gross wrote:
> On 08/11/16 11:41, Wei Liu wrote:
> > On Tue, Nov 08, 2016 at 07:29:01AM +0100, Juergen Gross wrote:
> >> The dependency for setting up the links for ioemu is wrong: it is
> >> depending on tools/qemu-xen-traditional-dir which is bein
Improving the output of xen-livepatch, which is currently hard to read,
especially when an error occurs.
Some examples of the changes:
Before:
$ xen-livepatch apply test
Performing apply:. completed
After:
$ xen-livepatch apply test
Applying test:. completed
Before:
$ xen-live
Using both stdout and stderr interleaved without newlines can result in
strange output when using line buffered mode (e.g. a terminal) or when
fully buffered (e.g. redirected to a file). Set both to unbuffered mode
to fix this.
Signed-off-by: Ross Lagerwall
---
tools/misc/xen-livepatch.c | 8 +++
The hypervisor already expects the timeout from the hypercall to be in
nanoseconds, so set this expectation everywhere.
Signed-off-by: Ross Lagerwall
---
tools/libxc/include/xenctrl.h | 2 +-
xen/common/livepatch.c| 4 ++--
xen/include/public/sysctl.h | 2 +-
3 files changed, 4 inserti
Exit with 0 for success.
Exit with 1 for an error.
Exit with 2 if the operation should be retried for any reason (e.g. a
timeout or because another operation was in progress).
This allows a program or script driving xen-livepatch to determine if
the operation should be retried without parsing the
Somewhat confusingly, before the action has been executed the patch is
expected to be in the "allowed" state, not the "expected" state. The
check for this was correct but the subsequent error message was not.
Fix the error message to show this state correctly.
Before:
$ xen-livepatch unload t
>>> On 12.12.16 at 17:19, wrote:
> On 12/12/2016 09:02 AM, Jan Beulich wrote:
> On 12.12.16 at 14:08, wrote:
>>> On 12/02/2016 02:48 AM, Jan Beulich wrote:
>>> On 01.12.16 at 17:43, wrote:
> On 12/01/2016 11:06 AM, Jan Beulich wrote:
>>> +++ b/xen/include/public/domctl.h
>>>
On Tue, Nov 29, 2016 at 10:33:08AM -0500, Boris Ostrovsky wrote:
> These registers (pm1a specifically) are not all specific to pm timer
> and are accessed by non-pmtimer code (for example, sleep/power button
> emulation).
>
> In addition to moving those regsters to struct hvm_domain rename
> HVM s
Hi, all!
Can anyone please point me to what PVMMU is and why it is
only supported for x86, but not ARM?
What I am trying to do is manually balloon in/out pages allocated
by my driver (with {alloc|free}_xenballooned_pages everything
works just fine, but this API gives me pages, while I want to u
On 12/12/2016 11:21 AM, Jan Beulich wrote:
On 12.12.16 at 17:01, wrote:
>> Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a
>> default ioreq server") breaks restore for HVM guests.
>>
>> I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log.
> And that's qemu-
Signed-off-by: Ross Lagerwall
---
tools/misc/xen-livepatch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index d683860..9633c4a 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -238,7 +238,6 @@ struct {
>>> On 09.12.16 at 16:44, wrote:
> Now, elf_load_image eventually calls elf_memcpy_safe, which calls
> elf_iter_ok_counted.
>
> So there is a work limit of 4x the image size. This is larger than
> the previous limit of 2x the image size, but it includes a lot of
> other processing too. And the
Hi all,
This series contains a few fixes to the xen-livepatch tool.
It also contains a few changes to make the output more readable.
Ross Lagerwall (7):
tools/livepatch: Show the correct expected state before action
tools/livepatch: Set stdout and stderr unbuffered
tools/livepatch: Improve
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 7/7]
make-flight/mfi-common: Add them in the matrix."):
> On Thu, Nov 17, 2016 at 12:24:20PM +, Ian Jackson wrote:
> > Can you accompany this with a diff of the output of
> >standalone-generate-dump-flight-runvars
> > before and afte
On 12/12/16 16:22, Paul Durrant wrote:
>> -Original Message-
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Sent: 12 December 2016 16:02
>> To: Paul Durrant ; Jan Beulich
>> ; Andrew Cooper ;
>> Juergen Gross ; xen-devel
>> Cc: zhangchen.f...@cn.fujitsu.com
>> Subject: ior
> -Original Message-
> From: Andrew Cooper
> Sent: 12 December 2016 16:27
> To: Paul Durrant ; Boris Ostrovsky
> ; Jan Beulich ; Juergen
> Gross ; xen-devel
> Cc: zhangchen.f...@cn.fujitsu.com
> Subject: Re: ioreq server regression
>
> On 12/12/16 16:22, Paul Durrant wrote:
> >> -Orig
On 12/12/2016 11:47 AM, Boris Ostrovsky wrote:
>
> Come think of it, maybe we should do this for all guests (which really
> means for HVM too)?
I meant, of course, for qemu-upstream HVM guests too.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xe
On Tue, Nov 29, 2016 at 10:33:19AM -0500, Boris Ostrovsky wrote:
[...]
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 33c5e4c..d80ab77 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5147,8 +5147,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t
> domid
Anthony PERARD writes ("[OSSTEST PATCH v8 1/3] ts-openstack-deploy: Deploy
OpenStack on a host with devstack"):
> This script installs any necessary packages and clones all of the OpenStack
> trees which are used by devstack to deploy OpenStack.
>
> Signed-off-by: Anthony PERARD
Acked-by: Ian J
Anthony PERARD writes ("[OSSTEST PATCH v8 0/3] Have OpenStack tested on top of
xen's master and libvirt's master."):
> I have looked into getting OpenStack been tested on the latest Xen via
> osstest.
> Run of AP_FETCH_PLACEHOLDERS=y ./standalone-generate-dump-flight-runvars on
> master (5d88d6299
On Mon, Dec 12, 2016 at 04:07:40PM +, Roger Pau Monne wrote:
> The path to the xenstore FreeBSD device is /dev/xen/xenstore.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 12 December 2016 16:02
> To: Paul Durrant ; Jan Beulich
> ; Andrew Cooper ;
> Juergen Gross ; xen-devel
> Cc: zhangchen.f...@cn.fujitsu.com
> Subject: ioreq server regression
>
> Looks like commit e7d
>>> On 05.12.16 at 20:36, wrote:
> Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
> The current MAX_IO_APICS is 128, which causes the driver initialization
> to fail on the system with IOAPIC ID >= 128.
>
> Instead, this patch adds APIC ID in the struct ioapic_sbdf,
>
Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok
and elf_strcmp_safe"):
> Well, I have to confess that I've read the above as max() when
> in fact it is min().
Sadly we can't use min() and max() here it seems.
> On 12.12.16 at 17:00, wrote:
> > The max_size_for_de
> -Original Message-
> From: Paul Durrant
> Sent: 12 December 2016 16:29
> To: Andrew Cooper ; Boris Ostrovsky
> ; Jan Beulich ; Juergen
> Gross ; xen-devel
> Cc: zhangchen.f...@cn.fujitsu.com
> Subject: RE: ioreq server regression
>
> > -Original Message-
> > From: Andrew Cooper
On 12/12/16 16:01, Boris Ostrovsky wrote:
> Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a
> default ioreq server") breaks restore for HVM guests.
>
> I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log.
>
> -boris
>
Does this help? The current creation_finish
On 12/12/2016 11:35 AM, Wei Liu wrote:
> On Tue, Nov 29, 2016 at 10:33:19AM -0500, Boris Ostrovsky wrote:
> [...]
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 33c5e4c..d80ab77 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -5147,8 +5147,14 @@ int libxl_
On Mon, Dec 12, 2016 at 04:18:04PM +, Ross Lagerwall wrote:
> Somewhat confusingly, before the action has been executed the patch is
> expected to be in the "allowed" state, not the "expected" state. The
ITYM "allow", according to your code.
> check for this was correct but the subsequent er
On Mon, Dec 12, 2016 at 04:18:05PM +, Ross Lagerwall wrote:
> Using both stdout and stderr interleaved without newlines can result in
> strange output when using line buffered mode (e.g. a terminal) or when
> fully buffered (e.g. redirected to a file). Set both to unbuffered mode
> to fix this.
On Mon, Dec 12, 2016 at 04:18:08PM +, Ross Lagerwall wrote:
> The default timeout in the hypervisor for a livepatch operation is 30 ms,
> but xen-livepatch currently waits for up to 30 seconds for the operation
> to complete. Instead, remove the retry loop and simply wait for 2 * 30 ms
> for th
On Mon, Dec 12, 2016 at 04:18:06PM +, Ross Lagerwall wrote:
> Improving the output of xen-livepatch, which is currently hard to read,
> especially when an error occurs.
>
> Some examples of the changes:
> Before:
> $ xen-livepatch apply test
> Performing apply:. completed
> After:
>
On Mon, Dec 12, 2016 at 04:18:10PM +, Ross Lagerwall wrote:
> Exit with 0 for success.
> Exit with 1 for an error.
> Exit with 2 if the operation should be retried for any reason (e.g. a
> timeout or because another operation was in progress).
>
> This allows a program or script driving xen-li
On Mon, Dec 12, 2016 at 04:18:07PM +, Ross Lagerwall wrote:
> The hypervisor already expects the timeout from the hypercall to be in
> nanoseconds, so set this expectation everywhere.
>
> Signed-off-by: Ross Lagerwall
> ---
> tools/libxc/include/xenctrl.h | 2 +-
> xen/common/livepatch.c
On Mon, Dec 12, 2016 at 04:18:09PM +, Ross Lagerwall wrote:
> Signed-off-by: Ross Lagerwall
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Mon, Dec 12, 2016 at 04:04:24PM +, Roger Pau Monne wrote:
> Update the structure of the FADT table to version 5, and use that version for
> PVHv2 guests. Note that HVM guests will continue to use FADT 4. In order to do
> this, add a new field to acpi_config that contains the ACPI revision to
On Mon, Dec 12, 2016 at 11:50:53AM -0500, Boris Ostrovsky wrote:
> On 12/12/2016 11:47 AM, Boris Ostrovsky wrote:
> >
> > Come think of it, maybe we should do this for all guests (which really
> > means for HVM too)?
>
> I meant, of course, for qemu-upstream HVM guests too.
>
Fine by me -- but p
On Wed, 2016-12-07 at 16:23 +, Ian Jackson wrote:
> ...
> I have an alternative concrete suggestion:
>
> Unless there are good reasons to diverge, our suggestions to
> discoverer(s) will be based on the following criteria, in order of
> precedence:
> 1. Avoiding disclosure on Fridays, week
On 12/12/2016 12:09 PM, Wei Liu wrote:
> On Mon, Dec 12, 2016 at 11:50:53AM -0500, Boris Ostrovsky wrote:
>> On 12/12/2016 11:47 AM, Boris Ostrovsky wrote:
>>> Come think of it, maybe we should do this for all guests (which really
>>> means for HVM too)?
>> I meant, of course, for qemu-upstream HVM
On Mon, Dec 12, 2016 at 12:14:36PM -0500, Boris Ostrovsky wrote:
> On 12/12/2016 12:09 PM, Wei Liu wrote:
> > On Mon, Dec 12, 2016 at 11:50:53AM -0500, Boris Ostrovsky wrote:
> >> On 12/12/2016 11:47 AM, Boris Ostrovsky wrote:
> >>> Come think of it, maybe we should do this for all guests (which re
On Mon, Dec 12, 2016 at 05:02:59PM +, Wei Liu wrote:
> On Mon, Dec 12, 2016 at 04:18:07PM +, Ross Lagerwall wrote:
> > The hypervisor already expects the timeout from the hypercall to be in
> > nanoseconds, so set this expectation everywhere.
> >
> > Signed-off-by: Ross Lagerwall
> > ---
On Mon, Dec 12, 2016 at 05:02:52PM +, Wei Liu wrote:
> On Mon, Dec 12, 2016 at 04:18:06PM +, Ross Lagerwall wrote:
> > Improving the output of xen-livepatch, which is currently hard to read,
> > especially when an error occurs.
> >
> > Some examples of the changes:
> > Before:
> > $ xe
On Mon, Dec 12, 2016 at 04:18:09PM +, Ross Lagerwall wrote:
> Signed-off-by: Ross Lagerwall
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> tools/misc/xen-livepatch.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
> index d683860.
On Mon, Dec 12, 2016 at 04:51:47PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[OSSTEST PATCH v8 0/3] Have OpenStack tested on top
> of xen's master and libvirt's master."):
> > I have looked into getting OpenStack been tested on the latest Xen via
> > osstest.
> > Run of AP_FETCH_PLACEHOL
Cédric Bosdonnat writes ("[PATCH v3] libxl: QED disks support"):
> Qdisk supports qcow and qcow2, extend it to also support qed disk
> format.
The patch is good.
I have a qualm, though. I think this would increase our security
support footprint to include the qemu qed disk format driver.
Specif
Anthony PERARD writes ("Re: [OSSTEST PATCH v8 0/3] Have OpenStack tested on top
of xen's master and libvirt's master."):
> On Mon, Dec 12, 2016 at 04:51:47PM +, Ian Jackson wrote:
> > The way you have done things, the test-amd64-amd64-devstack job will
> > run on a Xen dom0 installed by osstes
Note that unlike most privilege restricted instructions, STAC and CLAC are
documented to raise #UD rather than #GP[0], and indeed do so.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Exclude the use of legacy prefixes. Their exclusion is undocumented but
consistent with observed b
On Mon, Dec 12, 2016 at 02:58:39AM -0700, Jan Beulich wrote:
> >>> On 12.12.16 at 10:28, wrote:
> > Instruction emulator fuzzing code is from code previous written by
> > Andrew and George. Adapted to llvm fuzzer and hook up the build system.
> >
> > Signed-off-by: Andrew Cooper
> > Signed-off-b
Wei Liu writes ("Re: [PATCH v3 5/7] tools/fuzz: introduce x86 instruction
emulator target"):
> On Mon, Dec 12, 2016 at 04:30:30AM -0700, Jan Beulich wrote:
>>> On 12.12.16 at 12:19, wrote:
> > > I mean "states". There are three states we need to reset.
> >
> > Hmm, to me as a non-native speaker
On Mon, Dec 12, 2016 at 05:59:40PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v3 5/7] tools/fuzz: introduce x86 instruction
> emulator target"):
> > On Mon, Dec 12, 2016 at 04:30:30AM -0700, Jan Beulich wrote:
> >>> On 12.12.16 at 12:19, wrote:
> > > > I mean "states". There are thre
On 12/12/2016 11:36 AM, Andrew Cooper wrote:
> On 12/12/16 16:01, Boris Ostrovsky wrote:
>> Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a
>> default ioreq server") breaks restore for HVM guests.
>>
>> I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log.
>>
>> -
101 - 200 of 260 matches
Mail list logo
