flight 145307 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
145025
Tests whic
This patch fixes the typo about the active status range of an IRQ
via GICD. Otherwise it will be failed to handle the mmio access and
inject a data abort.
Fixes: a2b83f95bfad ("xen/arm: vgic: Properly emulate the full register")
Signed-off-by: Wei Xu
---
xen/arch/arm/vgic-v3.c | 2 +-
1 file ch
flight 145301 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145301/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
flight 145304 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145304/
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
flight 145295 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
145025
Regression
flight 145298 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145298/
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
flight 145287 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
On 02/12/2019 08:22, Andy Smith wrote:
> Hi,
>
> I've been looking into live patching for the first time.
CC'ing livepatch maintainers.
>
> Starting with a 4.12.1 build:
>
> $ cd ~/dev
> $ ls -l
> total 8
> drwxr-xr-x 3 andy andy 4096 Oct 25 16:11 xen
> drwxr-xr-x 6 andy andy 4096 Dec 2 01:16 li
On 12/27/19 4:32 PM, George Dunlap wrote:
> The current fromC array code will do the "magic" casting and
> martialling even when num_foo variable is 0. Go crashes when doing
> the cast.
>
> Furthermore, the current toC array code will convert a nil slice into
> a zero-length malloc. The resultin
This is a sketch of functionality suitable for creating a basic
domain, with a disk and a vif. DomainConfig, DeviceDisk, and
DeviceNic types are all created using constructor functions, which
initialize them with libxl's defaults.
DomainCreateNew takes the config and calls without any updates.
O
The current fromC array code will do the "magic" casting and
martialling even when num_foo variable is 0. Go crashes when doing
the cast.
Furthermore, the current toC array code will convert a nil slice into
a zero-length malloc. The resulting pointer is non-NULL, and confuses
libxl.
Only do ar
If an error is encountered deep in a complicated data structure, it's
often difficult to tell where the error actually is. Make the error
message from the generated toC() and fromC() structures more
informative by tagging which field being converted encountered the
error. This will have the effec
C.GoString will handle NULL C strings properly, by passing back "".
But C.CString will take an empty Go string and actually generate a
'\0'-terminated empty string. This confuses libxl, which is expecting
non-values to be NULL, not "".
Only call C.CString if the Go string is non-empty.
Signed-of
Empty Go strings should be converted to `nil` libxl_cpuid_policy_list;
otherwise libxl_cpuid_parse_config gets confused.
Also, libxl_cpuid_policy_list returns a weird error, not a "normal"
libxl error; if it returns one of these non-standard errors, convert
it to ErrorInval.
Signed-off-by: George
Commit 871e51d2d4 changed the sign on the xenlight error types (making
the values negative, same as the C-generated constants), but failed to
flip the sign in the Error() string function. The result is that
ErrorNonspecific.String() prints "libxl error: 1" rather than the
human-readable error mess
libxl forks external processes and waits for them to complete; it
therefore needs to be notified when children exit.
In absence of instructions to the contrary, libxl sets up its own
SIGCHLD handlers.
Golang always unmasks and handles SIGCHLD itself. libxl thankfully
notices this and throws an a
Signed-off-by: George Dunlap
---
The other option would be to expose the XTL logging levels and let the
caller set them somehow.
CC: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/golang/xenlight/xenlight.go
b/tool
Similar to the autogenerated types, but for `builtin` Bitmap type.
Signed-off-by: George Dunlap
---
CC: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/golang/xenlight/xenlight.go
b/tools/g
On 20/12/2019 16:23, Jan Beulich wrote:
> On 16.09.2019 11:40, Jan Beulich wrote:
>> Using memcpy() may result in multiple individual byte accesses
>> (dependening how memcpy() is implemented and how the resulting insns,
>> e.g. REP MOVSB, get carried out in hardware), which isn't what we
>> want/n
On 20/12/2019 13:50, Jan Beulich wrote:
> It is wrong for us to check the base address when there's no LDT in the
> first place. Once we don't do this check anymore we can also set the
> base address to a non-canonical value when the LDT is empty.
>
> Signed-off-by: Jan Beulich
I've only just spo
Hi George,
I was expecting a bigger list of CC here. What did you use to compute it?
On Mon, 23 Dec 2019, 17:45 George Dunlap, wrote:
> In order to better test hypervisor preemption paths, add an option to
> artificially increase the number of preemptions.
>
> While modifying xen-command-line.p
flight 145292 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145292/
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
On 20/12/2019 13:49, Jan Beulich wrote:
> It is wrong for us to check frames beyond the guest specified limit
> (in the native case, other than in the compat one).
>
> Signed-off-by: Jan Beulich
Just like the restriction on sharing L2's, no guest is ever going to be
able to not zero all of this t
On 24/12/2019 12:44, Roger Pau Monne wrote:
> If the flush mask matches the mask of online CPUs use the APIC ALLBUT
> destination shorthand in order to send an IPI to all CPUs on the
> system except the current one. This can only be safely used when no
> CPU hotplug or unplug operations are taking
On 24/12/2019 13:26, Roger Pau Monne wrote:
> Use Xen's L0 HVMOP_flush_tlbs hypercall when available in order to
> perform flushes. This greatly increases the performance of tlb flushes
> when running with a high amount of vCPUs as a Xen guest, and is
> specially important when running in shim mode
On 24/12/2019 13:26, Roger Pau Monne wrote:
> There's no need to call paging_update_cr3 unless CR3 trapping is
> enabled, and that's only the case when using shadow paging or when
> requested for introspection purposes, otherwise there's no need to
> pause all the vCPUs of the domain in order to pe
On Fri, Dec 27, 2019 at 6:44 AM Jan Beulich wrote:
>
> On 27.12.2019 14:10, Tamas K Lengyel wrote:
> > On Fri, Dec 27, 2019 at 1:04 AM Jan Beulich wrote:
> >>
> >> (re-sending, as I still don't see the mail having appeared on the list)
> >>
> >> On 23.12.2019 15:55, Tamas K Lengyel wrote:
> >>> O
On 23/12/2019 16:43, George Dunlap wrote:
> In order to better test hypervisor preemption paths, add an option to
> artificially increase the number of preemptions.
>
> While modifying xen-command-line.pandoc, escape some underscores
This is pandoc, not markdown, and underscores like these are one
On 27.12.2019 14:03, Andrew Cooper wrote:
> Saves 8 bytes in the trampoline.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 27.12.2019 14:38, Andrew Cooper wrote:
> Despite as suggested in c/s 685e922d6f3, not all HVM_PARAMs are handled
> in the same way. HVM_PARAM_PAE_ENABLED is a toolstack-only value, and
> the xc_cpuid_apply_policy() used to be the only consumer.
>
> Reinstate the old behaviour (mad as it is) to
On 27.12.2019 14:45, Andrew Cooper wrote:
> The call to xc_domain_disable_migrate() is made only from x86, while its
> handling in Xen is common. Move it to the libxl__build_pre().
>
> hvm_set_conf_params(), hvm_set_viridian_features(),
> hvm_set_mca_capabilities(), and the altp2m logic is all in
The call to xc_domain_disable_migrate() is made only from x86, while its
handling in Xen is common. Move it to the libxl__build_pre().
hvm_set_conf_params(), hvm_set_viridian_features(),
hvm_set_mca_capabilities(), and the altp2m logic is all in common
code (parts ifdef'd) but despite this, is al
On 27.12.2019 14:10, Tamas K Lengyel wrote:
> On Fri, Dec 27, 2019 at 1:04 AM Jan Beulich wrote:
>>
>> (re-sending, as I still don't see the mail having appeared on the list)
>>
>> On 23.12.2019 15:55, Tamas K Lengyel wrote:
>>> On Mon, Dec 23, 2019 at 2:37 AM Jan Beulich wrote:
On 20.1
our @msgs() is an array of $msginfo's where the first element is a
unique number. The $msgnum_used check ensures they are unique. Instead
if specifying them explicitly, generate msgnum locally. This reduces
the diff necessary to edit the middle of the @msgs() array.
All other hunks are adjustin
Despite as suggested in c/s 685e922d6f3, not all HVM_PARAMs are handled
in the same way. HVM_PARAM_PAE_ENABLED is a toolstack-only value, and
the xc_cpuid_apply_policy() used to be the only consumer.
Reinstate the old behaviour (mad as it is) to avoid regressions.
Signed-off-by: Andrew Cooper
-
flight 145279 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
145025
Regression
On 24.12.2019 16:32, Roger Pau Monne wrote:
> According to the Intel SDM, "virtualize x2APIC mode" and "virtualize
> APIC accesses" can't be enabled at the same time, or else a
> vm{launch/entry} failure will happen. This was seen when running Xen
> nested and with x2APIC enabled:
>
> Dec 23 20:06
On Fri, Dec 27, 2019 at 1:04 AM Jan Beulich wrote:
>
> (re-sending, as I still don't see the mail having appeared on the list)
>
> On 23.12.2019 15:55, Tamas K Lengyel wrote:
> > On Mon, Dec 23, 2019 at 2:37 AM Jan Beulich wrote:
> >>
> >> On 20.12.2019 18:32, Andrew Cooper wrote:
> >>> On 20/12/
Saves 8 bytes in the trampoline.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/trampoline.S | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
ind
On 27.12.2019 11:52, George Dunlap wrote:
> On 12/27/19 7:59 AM, Jan Beulich wrote:
>> On 23.12.2019 19:08, George Dunlap wrote:
>>> What about the attached series of patches (compile-tested only)?
>>
>> This ...
>>
>>> +#define nospec_clip(index, size) \
>>> +({
On 27.12.2019 12:27, Julien Grall wrote:
> Hi Jan,
>
> On Fri, 27 Dec 2019, 09:22 Jan Beulich, wrote:
>
>> On 23.12.2019 18:33, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 20/12/2019 14:55, Jan Beulich wrote:
There's been effectively no use of the field for HVM.
Also shrink the fie
Hi Jan,
On Fri, 27 Dec 2019, 09:22 Jan Beulich, wrote:
> On 23.12.2019 18:33, Julien Grall wrote:
> > Hi Jan,
> >
> > On 20/12/2019 14:55, Jan Beulich wrote:
> >> There's been effectively no use of the field for HVM.
> >>
> >> Also shrink the field to unsigned int, even if this doesn't immediate
flight 145286 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145286/
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
On 12/27/19 7:59 AM, Jan Beulich wrote:
> On 23.12.2019 19:08, George Dunlap wrote:
>> What about the attached series of patches (compile-tested only)?
>
> This ...
>
>> +#define nospec_clip(index, size) \
>> +({ \
>> +bool cli
flight 145270 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
test-amd64-i386-f
On 23.12.2019 18:33, Julien Grall wrote:
> Hi Jan,
>
> On 20/12/2019 14:55, Jan Beulich wrote:
>> There's been effectively no use of the field for HVM.
>>
>> Also shrink the field to unsigned int, even if this doesn't immediately
>> yield any space benefit for the structure itself. The resulting 3
(re-sending, as I still don't see the mail having appeared on the list)
On 23.12.2019 15:04, Alexandru Stefan ISAILA wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -46,6 +46,16 @@ struct xen_hvm_altp2m_suppress_ve {
> uint64_t gfn;
> };
>
> +str
(re-sending, as I still don't see the mail having appeared on the list)
On 23.12.2019 15:04, Alexandru Stefan ISAILA wrote:
> Changes since V5:
> - Add black lines
Luckily no color comes through in plain text mails ;-)
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access
(re-sending, as I still don't see the mail having appeared on the list)
On 23.12.2019 17:43, George Dunlap wrote:
> No functional changes.
>
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.o
(re-sending, as I still don't see the mail having appeared on the list)
On 23.12.2019 15:55, Tamas K Lengyel wrote:
> On Mon, Dec 23, 2019 at 2:37 AM Jan Beulich wrote:
>>
>> On 20.12.2019 18:32, Andrew Cooper wrote:
>>> On 20/12/2019 17:27, Tamas K Lengyel wrote:
On Fri, Dec 20, 2019 at 9:4
On 23.12.2019 19:08, George Dunlap wrote:
> What about the attached series of patches (compile-tested only)?
This ...
>+#define nospec_clip(index, size) \
>+({ \
>+bool clipped = (index >= size); \
>+index = ar
51 matches
Mail list logo
