flight 141693 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 140282
test-amd64-i386-f
flight 141691 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141691/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 141630
test-amd64-amd64-xl-qemut-win7-amd64
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here is a proposal of auto propagation for local_err, to not call
> error_propagate on every exit point, when we deal with local_err.
>
> It also fixes two issues:
> 1. Fix issue with error_fatal & error_append_hint: user can'
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Here is introduced ERRP_FUNCTION_BEGIN macro, to be used at start of
> any function with errp parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal & error_append_hint: user can't see these
> hints, because exit() happens i
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> scripts/coccinelle/auto-propagated-errp.cocci | 82 +++
> 1 file changed, 82 insertions(+)
> create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
>
> diff -
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Error **errp is almost always OUT-argument: it's assumed to be NULL, or
> pointer to NULL-initialized pointer, or pointer to error_abort or
> error_fatal, for callee to report error.
>
> But very few functions (most of the are error API) i
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> fit_load_fdt forget to zero errp. Fix it.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> hw/core/loader-fit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Independent bug fix. Either we take the (fixed) 2-3 (to r
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
A "why" as the commit message body wouldn't hurt.
> include/qapi/error.h | 22 ++
> util/error.c | 6 +++---
> 2 files changed, 25 insertions(+), 3 deletions
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> Don't shadow Error *err: it's a bad thing. This patch also simplifies
> following Error propagation conversion.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> net/net.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(
On 9/23/19 11:12 AM, Vladimir Sementsov-Ogievskiy wrote:
> This commit is generated by command
>
> git grep -l 'Error \*\*errp' | while read f; \
> do spatch --sp-file \
> scripts/coccinelle/auto-propagated-errp.cocci --in-place $f; done
>
As mentioned in your cover letter, this fails syntax-che
flight 141676 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
flight 141701 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141701/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
flight 141722 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141722/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-rochester02 hosts-allocate starved n/a
examine-elbling0 2 hosts-allocate
Hi George,
I made the changes that we discussed WRT C to Go type marshaling. See [1] for
generated code.
In addition, I took a pass at implementing Go to C type marshaling. The
generated toC functions are also in [1].
Finally, I made the necessary changes[2] to the existing xenlight.go so that
flight 141683 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141683/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141415
test-armhf-armhf-libvirt-raw 13 saveresto
flight 141673 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141673/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-i386-xl-qemuu-win10-i386
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org
On 9/20/19 1:28 AM, Jan Beulich wrote:
> On 19.09.2019 23:38, Joe Jin wrote:
>> On 9/19/19 3:24 AM, Jan Beulich wrote:
>>> What's
>>> still missing is the further updating of pirq_dpci->gmsi.dest_vcpu_id
>>> (as explained before, still visible in context above).
>>>
>>
>> 422
>> 423 dest_
On 9/23/19 3:05 PM, Eric Blake wrote:
> Does running this Coccinelle script 2 times in a row add a second
> ERRP_FUNCTION_BEGIN() line? We want it to be idempotent (no changes on
> a second run). (Admittedly, I did not actually test that yet). Also, I
> don't know if this can be tweaked to avoi
flight 141657 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141657/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141599 REGR.
vs. 139698
Tests which
On 23/09/2019 09:29, Jan Beulich wrote:
> On 20.09.2019 15:54, Jan Beulich wrote:
>> Recent AMD processors may report up to 128 logical processors in CPUID
>> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
>> as the respective field is only 8 bits wide. Suppress doubling the
flight 141718 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141718/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
certs/Kconfig | 14 ++---
init/Kconfig | 28 +-
I don't understand, why these special cases are not handled by
coccinelle. Possibly, it's a bug in coccinelle itself.
If no other ideas, these fixes may be just merged to autogenerated
commit(commits), with appropriate notice in commit message.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
ba
Hi all!
Here is a proposal of auto propagation for local_err, to not call
error_propagate on every exit point, when we deal with local_err.
It also fixes two issues:
1. Fix issue with error_fatal & error_append_hint: user can't see these
hints, because exit() happens in error_setg earlier than hi
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
scripts/coccinelle/auto-propagated-errp.cocci | 82 +++
1 file changed, 82 insertions(+)
create mode 100644 scripts/coccinelle/auto-propagated-errp.cocci
diff --git a/scripts/coccinelle/auto-propagated-errp.cocci
b/scripts/coccine
fit_load_fdt forget to zero errp. Fix it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/core/loader-fit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/loader-fit.c b/hw/core/loader-fit.c
index 953b16bc82..fe5bcc6700 100644
--- a/hw/core/loader-fit.c
+++ b/hw/c
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
arch/Kconfig | 4 ++--
arch/alpha/Kconfig | 2 +-
arch/arm/Kconfig
Here is introduced ERRP_FUNCTION_BEGIN macro, to be used at start of
any function with errp parameter.
It has three goals:
1. Fix issue with error_fatal & error_append_hint: user can't see these
hints, because exit() happens in error_setg earlier than hint is
appended. [Reported by Greg Kurz]
2.
Error **errp is almost always OUT-argument: it's assumed to be NULL, or
pointer to NULL-initialized pointer, or pointer to error_abort or
error_fatal, for callee to report error.
But very few functions (most of the are error API) instead get Error
**errp as IN-argument: it's assumed to be set, and
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qapi/error.h | 22 ++
util/error.c | 6 +++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/include/qapi/error.h b/include/qapi/error.h
index f6f4fa0fac..551385aa91 100644
--- a/include/qapi/er
Don't shadow Error *err: it's a bad thing. This patch also simplifies
following Error propagation conversion.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
net/net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/net.c b/net/net.c
index 84aa6d8d00..5fc72511c1 100
Hmm. Should we allow empty stubs with errp parameter without calling
new macro?
Or, just apply this commit before auto-generated commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
target/ppc/kvm_ppc.h| 2 ++
target/s390x/cpu_models.h | 1 +
hw/i386/kvm/apic.c | 1 +
hw/m
On 9/23/19 5:38 AM, Paul Durrant wrote:
>> -Original Message-
>> From: John Snow
>> Sent: 20 September 2019 22:11
>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>> qemu-de...@nongnu.org;
>> qemu-bl...@nongnu.org
>> Cc: Kevin Wolf ; Stefano Stabellini
>> ; Max Reitz
>> ; Anthony
On 20/09/2019 14:54, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0x8008 counterpart
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:25
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 8/8] AMD/IOMMU: pre-fill all DTEs right after
> table allocation
>
> Ma
On 15/07/2019 16:01, Jan Beulich wrote:
> Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
> often for relatively simple leaf functions. (To give a specific example,
> the case I've run into this with is _pci_hide_device() and gcc 8.
> Interestingly the even more simple neig
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:25
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 7/8] AMD/IOMMU: allocate one device table per
> PCI segment
>
> Having
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:24
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 6/8] AMD/IOMMU: tidy struct ivrs_mappings
>
> Move the device flags fiel
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:24
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 5/8] AMD/IOMMU: restrict interrupt remapping
> table sizes
>
> There's
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 4/8] AMD/IOMMU: replace INTREMAP_ENTRIES
>
> Prepare for the number of e
On 23/09/2019 16:12, Jan Beulich wrote:
> On 23.09.2019 16:20, Andrew Cooper wrote:
>> On 15/07/2019 16:00, Jan Beulich wrote:
>>> Nothing guarantees that the original frame's stack pointer points at
>>> readable memory. Avoid a (likely nested) crash by attaching exception
>>> recovery to the read
On 23.09.2019 17:57, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 19 September 2019 14:23
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Wei Liu ;
>> Suravee Suthikulpanit
>> ; Roger Pau Monne
>> Subject: [Xen-devel] [PA
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ;
> Suravee Suthikulpanit
> ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v6 3/8] x86/PCI: read maximum MSI vector count
On 14.09.2019 10:52, Juergen Gross wrote:
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -36,26 +36,35 @@ static DEFINE_SPINLOCK(cpupool_lock);
>
> DEFINE_PER_CPU(struct cpupool *, cpupool);
>
> +static void free_cpupool_struct(struct cpupool *c)
> +{
> +if ( c )
> +{
>
On 9/23/19 1:31 AM, Chao Gao wrote:
> On Wed, Sep 18, 2019 at 02:16:13PM -0700, Joe Jin wrote:
>> On 9/16/19 11:48 PM, Jan Beulich wrote:
>>> On 17.09.2019 00:20, Joe Jin wrote:
On 9/16/19 1:01 AM, Jan Beulich wrote:
> On 13.09.2019 18:38, Joe Jin wrote:
>> On 9/13/19 12:14 AM, Jan Beu
On 14.09.2019 10:52, Juergen Gross wrote:
> cpupool_domain_cpumask() is used by scheduling to select cpus or to
> iterate over cpus. In order to support scheduling units spanning
> multiple cpus let cpupool_domain_cpumask() return a cpumask with only
> one bit set per scheduling resource.
I guess
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:22
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 2/8] AMD/IOMMU: make phantom functions share
> interrupt remapping table
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -266,15 +267,16 @@ static inline void vcpu_runstate_change(
> static inline void sched_unit_runstate_change(struct sched_unit *unit,
> bool running, s_time_t new_entry_time)
> {
> -struct vcpu *v = unit->vcpu_list;
> +struct vcpu *v;
>
On 9/23/19 3:05 PM, Alexandru Stefan ISAILA wrote:
> A/D bit writes (on page walks) can be considered benign by an introspection
> agent, so receiving vm_events for them is a pessimization. We try here to
> optimize by filtering these events out.
> Currently, we are fully emulating the instruction
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:22
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 1/8] AMD/IOMMU: don't blindly allocate
> interrupt remapping tables
>
>
On 23.09.2019 17:18, Roger Pau Monné wrote:
> On Mon, Sep 23, 2019 at 04:41:01PM +0200, Jan Beulich wrote:
>> On 23.09.2019 16:22, Roger Pau Monné wrote:
>>> On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
Rather than doing this every time we set up interrupts for a device
On 14.09.2019 10:52, Juergen Gross wrote:
> Today the vcpu runstate of a new scheduled vcpu is always set to
> "running" even if at that time vcpu_runnable() is already returning
> false due to a race (e.g. with pausing the vcpu).
I can see this part, ...
> With core scheduling this can no longer
On Mon, Sep 23, 2019 at 04:41:01PM +0200, Jan Beulich wrote:
> On 23.09.2019 16:22, Roger Pau Monné wrote:
> > On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
> >> Rather than doing this every time we set up interrupts for a device
> >> anew (and then in several places) fill this inva
On Fri, Sep 20, 2019 at 06:02:50PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> > On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> > > Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> > > bypassing pciba
On 23.09.2019 16:20, Andrew Cooper wrote:
> On 15/07/2019 16:00, Jan Beulich wrote:
>> Nothing guarantees that the original frame's stack pointer points at
>> readable memory. Avoid a (likely nested) crash by attaching exception
>> recovery to the read (making it a single read at the same time). Do
flight 141650 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 141519
Tests which are faili
On Wed, Sep 18, 2019 at 12:57:44PM +0100, Paul Durrant wrote:
> From: Mark Syms
>
> Some toolstack implementations will set the frontend xenstore
> keys to Initialising which will then trigger the in guest PV
> drivers to begin initialising and some implementations will
> then set their state to
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drive
On Mon, Sep 23, 2019 at 02:39:10PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 23 September 2019 15:21
> > To: Paul Durrant
> > Cc: 'Wei Liu' ; Xen Development List
> > ; Wei Liu
> > ; Andrew Cooper ; Michael
> > Kelley
> > ; Jan Beulich ; Roger Pau Mon
On 23.09.2019 16:22, Roger Pau Monné wrote:
> On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
>> Rather than doing this every time we set up interrupts for a device
>> anew (and then in several places) fill this invariant field right after
>> allocating struct pci_dev.
>>
>> Signed-of
> -Original Message-
> From: Wei Liu
> Sent: 23 September 2019 15:21
> To: Paul Durrant
> Cc: 'Wei Liu' ; Xen Development List
> ; Wei Liu
> ; Andrew Cooper ; Michael
> Kelley
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
flight 141708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 141253
Tests which
On Mon, Sep 23, 2019 at 01:47:14PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 23 September 2019 14:34
> > To: Paul Durrant
> > Cc: 'Wei Liu' ; Xen Development List
> > ; Wei Liu
> > ; Andrew Cooper ; Michael
> > Kelley
> > ; Jan Beulich ; Roger Pau Mon
On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
> Rather than doing this every time we set up interrupts for a device
> anew (and then in several places) fill this invariant field right after
> allocating struct pci_dev.
>
> Signed-off-by: Jan Beulich
LGTM:
Reviewed-by: Roger Pau M
On 15/07/2019 16:00, Jan Beulich wrote:
> Nothing guarantees that the original frame's stack pointer points at
> readable memory. Avoid a (likely nested) crash by attaching exception
> recovery to the read (making it a single read at the same time). Don't
> even invoke _show_trace() in case of a no
On 23.09.2019 16:05, Paul Durrant wrote:
>> -Original Message-
>> From: Alexandru Stefan ISAILA
>> Sent: 23 September 2019 13:06
>> To: xen-devel@lists.xenproject.org
>> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
>> ; w...@xen.org; Roger Pau Monne
>> ; Razvan COJOCARU
>> ; ta..
On 23.09.2019 16:43, Jan Beulich wrote:
> On 23.09.2019 14:05, Alexandru Stefan ISAILA wrote:
>> @@ -599,8 +600,15 @@ static void *hvmemul_map_linear_addr(
>> err = NULL;
>> goto out;
>>
>> -case HVMTRANS_gfn_paged_out:
>> +case HVMTRANS_need_retry:
> -Original Message-
> From: Wei Liu
> Sent: 23 September 2019 14:34
> To: Paul Durrant
> Cc: 'Wei Liu' ; Xen Development List
> ; Wei Liu
> ; Andrew Cooper ; Michael
> Kelley
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
On 23.09.2019 14:05, Alexandru Stefan ISAILA wrote:
> @@ -599,8 +600,15 @@ static void *hvmemul_map_linear_addr(
> err = NULL;
> goto out;
>
> -case HVMTRANS_gfn_paged_out:
> +case HVMTRANS_need_retry:
> +/*
> + * hvm_translate_get
> On 23 Sep 2019, at 14:39, Paul Durrant wrote:
>
> Ping? I think this is the only remaining patch in this series that still
> needs an ack.
Acked-by: Christian Lindig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
On 23.09.19 16:31, Jan Beulich wrote:
Hi, Jan
+
+ if ( ptr == NULL || ptr == ZERO_BLOCK_PTR )
+ return _xmalloc(size, align);
+
+ ASSERT((align & (align - 1)) == 0);
+ if ( align < MEM_ALIGN )
+ align = MEM_ALIGN;
+
+ tmp_size = size + align - MEM_ALIGN;
+
+ if (
Ping? I think this is the only remaining patch in this series that still needs
an ack.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 18 September 2019 11:47
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Paul Durrant
> ; Christian Lindig
> ; David Scott
> Subject:
Wei Liu writes ("Re: [PATCH] libxl: Fix build when LIBXL_API_VERSION is set"):
> On Mon, Sep 23, 2019 at 02:26:52PM +0100, Anthony PERARD wrote:
> > The compatibility function mistakenly called itself.
> >
> > Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
> > Signed-off-by: Anthony PERARD
>
>
On Mon, Sep 23, 2019 at 02:26:52PM +0100, Anthony PERARD wrote:
> The compatibility function mistakenly called itself.
>
> Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing list
Xe
And a bit more thought.
On Mon, Sep 23, 2019 at 01:54:31PM +0100, Wei Liu wrote:
[...]
> > >
> > > Per TLFS, eVMCS should be used by L1 Xen.
> >
> > Yes, I guess it only needs to be used by L1, but Windows is using an
> > increasing number of VMs for various purposes so I think making it
> > sta
On 23.09.2019 14:50, Oleksandr wrote:
> Does the diff below is close to what you meant?
Almost.
> @@ -598,10 +621,70 @@ void *_xzalloc(unsigned long size, unsigned long align)
> return p ? memset(p, 0, size) : p;
> }
>
> -void xfree(void *p)
> +void *_xrealloc(void *ptr, unsigned long si
The compatibility function mistakenly called itself.
Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index ba48e7e900d3..3421e5aa986
On Mon, Sep 23, 2019 at 03:02:49PM +0200, Jan Beulich wrote:
> On 23.09.2019 14:25, Marek Marczykowski-Górecki wrote:
> > What about this: HVM guest can already do all of this when qemu is
> > running in dom0. So, allowing those actions when qemu is running in
> > stubdomain should not introduce _
> -Original Message-
> From: Alexandru Stefan ISAILA
> Sent: 23 September 2019 13:06
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; w...@xen.org; Roger Pau Monne
> ; Razvan COJOCARU
> ; ta...@tklengyel.com; Alexandru Stefan ISAILA
> ;
> Pet
On 23.09.2019 14:25, Marek Marczykowski-Górecki wrote:
> What about this: HVM guest can already do all of this when qemu is
> running in dom0. So, allowing those actions when qemu is running in
> stubdomain should not introduce _additional_ risks.
Well, in a way - yes. But I don't think it's righ
On Mon, Sep 23, 2019 at 12:11:26PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 23 September 2019 12:27
> > To: Paul Durrant
> > Cc: 'Wei Liu' ; Xen Development List
> > ; Wei Liu
> > ; Andrew Cooper ; Michael
> > Kelley
> > ; Jan Beulich ; Roger Pau Mon
On 16.09.19 18:24, Jan Beulich wrote:
Hi, Jan.
+ROUNDUP_SIZE(tmp_size);
+
+if ( tmp_size <= curr_size && ((unsigned long)ptr & (align - 1)) == 0 )
+return ptr; /* the size and alignment fit in already allocated space */
You also don't seem to ever update ptr in case yo
On Mon, Sep 23, 2019 at 02:05:58PM +0200, Jan Beulich wrote:
> On 23.09.2019 12:47, Marek Marczykowski-Górecki wrote:
> > On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> >> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> >>> Anyway, if you all agree that pciback should be
> -Original Message-
> From: Wei Liu
> Sent: 23 September 2019 12:27
> To: Paul Durrant
> Cc: 'Wei Liu' ; Xen Development List
> ; Wei Liu
> ; Andrew Cooper ; Michael
> Kelley
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
On 23.09.2019 12:47, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
>> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
>>> Anyway, if you all agree that pciback should be the way to go, I can go
>>> that route too. In practice, it would be
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by filtering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind
On Wed, Sep 18, 2019 at 12:57:02PM +0100, Paul Durrant wrote:
> When a frontend gracefully disconnects from an offline backend, it will
> set its own state to XenbusStateClosed. The code in xen-block.c correctly
> deals with this and sets the backend into XenbusStateClosed. Unfortunately
> it is po
On Mon, Sep 23, 2019 at 10:48:45AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Wei
> > Liu
> > Sent: 23 September 2019 11:09
> > To: Xen Development List
> > Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> > ;
> > Michael Kelley ; Jan Beulich ;
> > Roger
flight 141640 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 141505
Tests which did not
> -Original Message-
> From: Xen-devel On Behalf Of Wei Liu
> Sent: 23 September 2019 11:09
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ;
> Michael Kelley ; Jan Beulich ;
> Roger Pau Monne
>
> Subject: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> >> On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> >>> Allow device model running in stubdomain to enab
On Fri, Sep 20, 2019 at 03:54:12PM +0200, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0
On 18/09/2019 19:50, Volodymyr Babchuk wrote:
Hello,
Hi,
This is the second version for maturing the OP-TEE mediator.
Changes also can be pulled from [2].
Changes from v1:
- Added patch that updates SUPPORT.md
- Instead of removing "experimental" status I changed it to "Tech Preview"
flight 141698 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
On 23.09.19 12:12, Jan Beulich wrote:
On 23.09.2019 11:56, Jürgen Groß wrote:
On 23.09.19 11:51, Jan Beulich wrote:
On 23.09.2019 11:42, Jürgen Groß wrote:
On 16.09.19 17:44, Jan Beulich wrote:
On 16.09.2019 16:50, Andrew Cooper wrote:
After a complicated investigation, it turns out that c/s
Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/ocaml: Build fix following
libxl API changes"):
> According to osstest results accumulated over the weekend and the
> state of the tree, did you perhaps commit the change but forgot
> to actually push it?
Gah, apparently so. Now done.
Ian.
___
On 23.09.2019 11:56, Jürgen Groß wrote:
> On 23.09.19 11:51, Jan Beulich wrote:
>> On 23.09.2019 11:42, Jürgen Groß wrote:
>>> On 16.09.19 17:44, Jan Beulich wrote:
On 16.09.2019 16:50, Andrew Cooper wrote:
> After a complicated investigation, it turns out that c/s 2529c850ea48
> broke
We will add Hyper-V specific implementations in the future.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/xen/xen.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/x
We use the same code structure as we did for Xen code.
As starters, detect Hyper-V in probe_hyperv. More complex
functionality will be added later.
Signed-off-by: Wei Liu
---
xen/arch/x86/Kconfig | 9 +
xen/arch/x86/guest/Makefile| 1 +
xen/arch/x86/guest/hyperv/Make
1 - 100 of 129 matches
Mail list logo
