Thanks for the responses.
On 1/22/21 12:35 AM, Dario Faggioli wrote:
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
Hi Dario,
Hi!
On 21/01/2021 18:32, Dario Faggioli wrote:
On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
https://lists.xenproject.org/archives/html/xen
On 1/21/21 7:32 PM, Dario Faggioli wrote:
On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
Hi,
Hello,
I see a problem with destroy and restart of a domain. Interrupts are
not
available when trying to restart a domain.
The situation seems very similar to the thread "null scheduler
On Wed, Jan 20, 2021 at 10:04:13AM +0100, Jan Beulich wrote:
> On 19.01.2021 19:43, osstest service owner wrote:
> > branch xen-unstable
> > xenbranch xen-unstable
> > job test-amd64-amd64-dom0pvh-xl-intel
> > testid xen-boot
> >
> > Tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/s
On 15.01.2021 15:28, Roger Pau Monne wrote:
> When pins are cleared from either ISR or IRR as part of the
> initialization sequence forward the clearing of those pins to the dpci
> EOI handler, as it is equivalent to an EOI. Not doing so can bring the
> interrupt controller state out of sync with t
On Fri, 2021-01-22 at 09:06 +0100, Anders Törnqvist wrote:
> On 1/22/21 12:35 AM, Dario Faggioli wrote:
>
>
> - booting with "sched=null" but not with "vwfi=native"
> Without "vwfi=native" it works fine to destroy and to re-create the
> domain.
> Both printouts comes after a destroy:
> (XEN) End
On 21.01.2021 19:47, Julien Grall wrote:
> On 21/01/2021 10:24, Jan Beulich wrote:
>> On 21.01.2021 10:56, Julien Grall wrote:
>>> On 21/01/2021 09:43, Jan Beulich wrote:
On 21.01.2021 10:30, Michal Orzel wrote:
> --- a/xen/include/asm-arm/early_printk.h
> +++ b/xen/include/asm-arm/ear
On 21.01.2021 18:45, Roger Pau Monné wrote:
> On Thu, Jan 21, 2021 at 05:23:04PM +0100, Jan Beulich wrote:
>> On 15.01.2021 15:28, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vioapic.c
>>> +++ b/xen/arch/x86/hvm/vioapic.c
>>> @@ -268,6 +268,17 @@ static void vioapic_write_redirent(
>>>
>>>
This is an overture of a major rework of the xenstored internals I've
had lying around for about one year now. It has been blocked by all
the XSA work and live update stuff.
This series has not seen much testing. It is rather meant as a
starting point for discussions whether the approach especiall
Xenstored is absolutely mandatory for a Xen host and it can't be
restarted, so being killed by OOM-killer in case of memory shortage is
to be avoided.
Set /proc/$pid/oom_score_adj (if available) to -500 in order to allow
xenstored to use large amounts of memory without being killed.
In order to s
Today all Xenstore nodes are stored in a TDB data base. This makes it
rather complicated to walk nodes for different purposes, as all walked
nodes need to be fetched from TDB before, and references between nodes
are difficult to handle.
So drop using TDB and store the nodes directly in memory maki
The main loop of xenstored is rather complicated due to different
handling of socket and ring-page interfaces. Unify that handling by
introducing interface type specific functions can_read() and
can_write().
Put the interface type specific functions in an own structure and let
struct connection co
Rework the interfaces to the hashtable code in order to adapt it better
to Xenstore:
- don't use user-specified hash- and compare-functions
- modify the type of the key to be const char *
- instead of using calloc() and free() switch to the talloc interfaces
- drop the due to talloc usage no longe
On 22.01.2021 01:51, Bobby Eshleman wrote:
> This is version 3 for a patch set sent out to the ML in 2018 [1] to
> support UEFI Secure Boot for Xen on multiboot2 platforms.
>
> A new binary, xen.mb.efi, is built. It contains the mb2 header as well
> as a hand-crafted PE/COFF header. The dom0 ker
Hi Boris,
On 20/01/2021 22:49, Boris Ostrovsky wrote:
This option allows guest administrator specify what should happen when
guest accesses an MSR which is not explicitly emulated by the hypervisor.
Signed-off-by: Boris Ostrovsky
---
docs/man/xl.cfg.5.pod.in | 20 +++-
On Fri, Jan 22, 2021 at 10:02:15AM +0100, Jan Beulich wrote:
> On 15.01.2021 15:28, Roger Pau Monne wrote:
> > When pins are cleared from either ISR or IRR as part of the
> > initialization sequence forward the clearing of those pins to the dpci
> > EOI handler, as it is equivalent to an EOI. Not d
Hi Boris,
On 20/01/2021 22:49, Boris Ostrovsky wrote:
diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
index 19168572fd3e..1f2abf6679d7 100644
--- a/tools/libs/light/libxl_dom.c
+++ b/tools/libs/light/libxl_dom.c
@@ -383,9 +383,10 @@ int libxl__build_pre(libxl__gc *gc, ui
On 22.01.2021 10:53, Roger Pau Monné wrote:
> On Fri, Jan 22, 2021 at 10:02:15AM +0100, Jan Beulich wrote:
>> On 15.01.2021 15:28, Roger Pau Monne wrote:
>>> When pins are cleared from either ISR or IRR as part of the
>>> initialization sequence forward the clearing of those pins to the dpci
>>> EO
Hi Oleksandr,
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> In the ideal world we would never get an undefined behavior when
> propagating the sign bit since that bit can only be set for access
> size smaller than the register size (i.e byte/half-word for aarch32,
> byte/half-w
On 22/01/2021 06:08, Juergen Gross wrote:
> Commit 7f97193e6aa858df ("tools/xenstore: add live update command to
> xenstore-control") introduced testing an unsigned value to be less
> than 0. Fix that.
>
> Fixes: 7f97193e6aa858df ("tools/xenstore: add live update command to
> xenstore-control")
> R
On 22.01.2021 01:51, Bobby Eshleman wrote:
> From: Daniel Kiper
>
> POSIX time is required to fill the TimeDateStamp field
> in the PE header.
>
> Use SOURCE_DATE_EPOCH if available, otherwise use
> `date +%s` (available on both Linux and FreeBSD).
>
> Signed-off-by: Daniel Kiper
> Signed-off-
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech Preview.
Major differences with regard to Linux driver are as follows:
2. Only Stage-2 translation is supported as compared to the Linux driver
that supports bot
On 15.01.2021 15:28, Roger Pau Monne wrote:
> Current interrupt pass though code will setup a timer for each
> interrupt injected to the guest that requires an EOI from the guest.
> Such timer would perform two actions if the guest doesn't EOI the
> interrupt before a given period of time. The firs
On 20.01.2021 23:49, Boris Ostrovsky wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -295,7 +295,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> *val)
> }
>
> /* Fallthrough. */
> -case 0x4200 ... 0x42ff:
> +case 0x4200 ... 0x
flight 158556 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158556/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 157627
test-amd64-amd64-xl-qcow219
On 22.01.21 13:37, Rahul Singh wrote:
Hi Rahul
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech Preview.
Major differences with regard to Linux driver are as follows:
2. Only Stage-2 translation is supported
On 20.01.2021 23:49, Boris Ostrovsky wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -164,6 +164,34 @@ int init_vcpu_msr_policy(struct vcpu *v)
> return 0;
> }
>
> +/* Returns true if policy requires #GP to the guest. */
> +bool guest_unhandled_msr(const struct vcpu *v, ui
On 15.01.21 23:28, Edwin Török wrote:
Signed-off-by: Edwin Török
---
Changed since V1:
* post publicly now that the XSA is out
---
docs/designs/xenstore-migration.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/designs/xenstore-migration.md
b/docs/designs/xensto
Hi,
At 16:10 +0100 on 14 Jan (1610640627), Jan Beulich wrote:
> This is a remnant from 32-bit days, having no place anymore where a
> shadow of this type would be created.
>
> Signed-off-by: Jan Beulich
> ---
> hash_{domain,vcpu}_foreach() have a use each of literal 15. It's not
> clear to me wh
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Nick Rosbrook
CC: George Dunlap
---
tools/golang/xenlight/helpers.gen.go | 3 +++
tools/golang/xenlight/types.gen.go | 2 ++
2 files changed, 5 insertions(+)
diff --git a/tools/golang/xenlight/helpers.gen.go
b/tools/golang/x
At 16:01 +0100 on 14 Jan (1610640090), Jan Beulich wrote:
> ... shadow adjustments towards not building 2- and 3-level code
> when !HVM. While the latter isn't functionally related to the
> former, it depends on some of the rearrangements done there.
The shadow changes look good, thank you!
Review
On 09/11/2020 14:36, Reiser, Hans wrote:
> Hi,
>
> I have seen several occasions with "dead" xentop processes consuming 100% CPU
> time, and tracked this down
> to the following problem:
>
> When the QEMU process the qmp_read function is communicating with terminates,
> qmp_read may enter an
> in
Dear Andrew,
Thanks for picking this up. Sure, I agree with your proposal.
Cheers, Hans
> On 2021-01-22, at 14:25, Andrew Cooper wrote:
>
> On 09/11/2020 14:36, Reiser, Hans wrote:
>> Hi,
>>
>> I have seen several occasions with "dead" xentop processes consuming 100%
>> CPU time, and tracked t
On 20/10/2020 13:39, Olaf Hering wrote:
> Files in the bash-completion dirs should be named like the commands,
> without suffix. Without this change 'xl' will not be recognized as a
> command with completion support if BASH_COMPLETION_DIR is set to
> /usr/share/bash-completion/completions.
>
> Fixe
Hi Dario,
On 21/01/2021 23:35, Dario Faggioli wrote:
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
Hi Dario,
Hi!
On 21/01/2021 18:32, Dario Faggioli wrote:
On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
https://lists.xenproject.org/archives/html/xen-devel/2018-09/m
Andrew Cooper writes ("[PATCH] golang/xenlight: Refresh generated helpers are
recent libxl changes"):
> Signed-off-by: Andrew Cooper
Can you please resend with something along these lines in the commit
message:
Results of running
No manual changes.
In which case, assuming that's tru
Andrew Cooper writes ("Re: [PATCH v1] xl: use proper name for bash_completion
file"):
> On 20/10/2020 13:39, Olaf Hering wrote:
> > Files in the bash-completion dirs should be named like the commands,
> > without suffix. Without this change 'xl' will not be recognized as a
> > command with complet
Hi Anders,
On 22/01/2021 08:06, Anders Törnqvist wrote:
On 1/22/21 12:35 AM, Dario Faggioli wrote:
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
- booting with "sched=null vwfi=native" but not doing the IRQ
passthrough that you mentioned above
"xl destroy" gives
(XEN) End of domain_d
On Fri, Jan 22, 2021 at 01:18:01PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
I think you mean "after recent" rather than "are recent" in your commit
message. But otherwise,
Acked-by: Nick Rosbrook
Thanks,
NR
flight 158557 xen-4.13-testing real [real]
flight 158573 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158557/
http://logs.test-lab.xenproject.org/osstest/logs/158573/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Fri, 2021-01-22 at 14:04 +0100, Jürgen Groß wrote:
> On 15.01.21 23:28, Edwin Török wrote:
> > Signed-off-by: Edwin Török
> > ---
> > Changed since V1:
> > * post publicly now that the XSA is out
> > ---
> > docs/designs/xenstore-migration.md | 3 ++-
> > 1 file changed, 2 insertions(+), 1 d
flight 158571 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158571/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
While the lack of proper dependency tracking of #include-d files is
wider than just the libs/ subtree, dealing with the problem universally
there or in tools/Rules.mk is too much of a risk at this point in the
release cycle. Add the missing inclusion of $(DEPS_INCLUDE) only in the
specific Makefil
flight 158558 xen-4.14-testing real [real]
flight 158575 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158558/
http://logs.test-lab.xenproject.org/osstest/logs/158575/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
Andrew Cooper writes ("[PATCH v7 01/10] xen+tools: Introduce
XEN_SYSCTL_PHYSCAP_vmtrace"):
> We're about to introduce support for Intel Processor Trace, but similar
> functionality exists in other platforms.
>
> Aspects of vmtrace can reasonably can be common, so start with
> XEN_SYSCTL_PHYSCAP_v
Andrew Cooper writes ("[PATCH v7 03/10] tools/[lib]xl: Add vmtrace_buf_size
parameter"):
> From: Michał Leszczyński
>
> Allow to specify the size of per-vCPU trace buffer upon
> domain creation. This is zero by default (meaning: not enabled).
Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH v7 07/10] tools/libxc: Add xc_vmtrace_*
functions"):
> From: Michał Leszczyński
>
> Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface.
Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH v7 08/10] tools/misc: Add xen-vmtrace tool"):
> From: Michał Leszczyński
...
> +if ( signal(SIGINT, int_handler) == SIG_ERR )
> +err(1, "Failed to register signal handler\n");
How bad is it if this signal handler is not effective ?
> +if ( xc_vmtrace
We are going to set other things here too. Prepare for that.
No functional change.
Signed-off-by: Ian Jackson
---
ts-xen-install | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ts-xen-install b/ts-xen-install
index feb98951..fc4bf423 100755
--- a/ts-xen-install
+++ b/t
This helps see what's going on without fishing individual
before-and-after files out of the log directory.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d2558f31..9e85303a 100644
---
This is the shell script config for xencommons. We are going to set
other things here too.
No functional change.
Signed-off-by: Ian Jackson
---
ts-xen-install | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ts-xen-install b/ts-xen-install
index 5d4f8b0d..feb98951 10
Previously, we let the Xen build system and startup scripts choose
which xenstored to use. Before we upgraded to Debian buster, that
gave us C xentored tests on ARM. Since then, armhf and arm64 have
both had enough ocaml support and we haven't been testing C xenstored
at all !
Change this, by se
Nothing sets this yet.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 1 +
ts-xen-install | 7 +++
2 files changed, 8 insertions(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 9e85303a..a0ca6943 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSu
No functional change with existing callers.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 9362a865..d2558f31 100644
--- a/Osstest/TestSuppo
We will use this in a moment.
Signed-off-by: Ian Jackson
---
mfi-common | 12
1 file changed, 12 insertions(+)
diff --git a/mfi-common b/mfi-common
index 34b0c116..35efd233 100644
--- a/mfi-common
+++ b/mfi-common
@@ -31,6 +31,18 @@ stripy () {
eval "$out_vn=\"\$out_$out_val\""
On 22/01/2021 15:56, Ian Jackson wrote:
> Previously, we let the Xen build system and startup scripts choose
> which xenstored to use. Before we upgraded to Debian buster, that
> gave us C xentored tests on ARM. Since then, armhf and arm64 have
> both had enough ocaml support and we haven't been
> Change this, by selecting between C xenstored and Ocaml xenstored
"at random"
Acked-by: Christian Lindig
From: Ian Jackson
Sent: 22 January 2021 15:56
To: xen-devel@lists.xenproject.org
Cc: Ian Jackson; Edwin Torok; Christian Lindig; Andrew Cooper; Jür
Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
> A couple of quick questions/observations. Does this cope in a sensible
> way if, for whatever reason, the chosen daemon isn't present?
That would depend on what you mean by "sensible". I think that given
that we no
On 22.01.21 17:22, Ian Jackson wrote:
Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
A couple of quick questions/observations. Does this cope in a sensible
way if, for whatever reason, the chosen daemon isn't present?
That would depend on what you mean by "sen
Jürgen Groß writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
> There is only stub C xenstored in our build.
I should have looked myself, shouldn't I:
-rw-r--r-- 1 osstest osstest 233391 Jan 21 22:14 xenstorepvh-stubdom.gz
-rw-r--r-- 1 osstest osstest 232653 Jan 21 22:14 xenstor
On 22.01.21 17:26, Ian Jackson wrote:
Jürgen Groß writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
There is only stub C xenstored in our build.
I should have looked myself, shouldn't I:
-rw-r--r-- 1 osstest osstest 233391 Jan 21 22:14 xenstorepvh-stubdom.gz
-rw-r--r-- 1 osst
On 22/01/2021 16:22, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy
> xenstored"):
>> A couple of quick questions/observations. Does this cope in a sensible
>> way if, for whatever reason, the chosen daemon isn't present?
> That would depend on what you me
On 22.01.2021 14:11, Tim Deegan wrote:
> At 16:10 +0100 on 14 Jan (1610640627), Jan Beulich wrote:
>> This is a remnant from 32-bit days, having no place anymore where a
>> shadow of this type would be created.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> hash_{domain,vcpu}_foreach() have a use each
On 22/01/2021 15:56, Ian Jackson wrote:
> diff --git a/mfi-common b/mfi-common
> index 35efd233..2834411f 100644
> --- a/mfi-common
> +++ b/mfi-common
> @@ -509,6 +509,13 @@ job_create_test () {
>xenbuildjob="${bfi}build-$xenarch$xsm_suffix"
>buildjob="${bfi}build-$dom0arch$xsm_suffix"
>
On Fri, 2021-01-22 at 15:56 +, Ian Jackson wrote:
> Previously, we let the Xen build system and startup scripts choose
> which xenstored to use. Before we upgraded to Debian buster, that
> gave us C xentored tests on ARM. Since then, armhf and arm64 have
> both had enough ocaml support and we
flight 158578 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158578/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 1/22/21 3:02 PM, Julien Grall wrote:
Hi Dario,
On 21/01/2021 23:35, Dario Faggioli wrote:
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
Hi Dario,
Hi!
On 21/01/2021 18:32, Dario Faggioli wrote:
On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
https://lists.xenproject
Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored"):
> Right, but nothing will actually fail the build.
Indeed.
> So the way this error will manifest is the first non-trivial `xl $FOO`
> executed in dom0 hanging until the job timeout.
I doubt it would produce a timeout
On 1/22/21 3:26 PM, Julien Grall wrote:
Hi Anders,
On 22/01/2021 08:06, Anders Törnqvist wrote:
On 1/22/21 12:35 AM, Dario Faggioli wrote:
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
- booting with "sched=null vwfi=native" but not doing the IRQ
passthrough that you mentioned above
On 22/01/2021 17:37, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy
> xenstored"):
>> Or does OSSTest have an explicit "is xenstored running" check after
>> boot, before any further testing occurs?
> No.
>
> If this turns out to ever happen we can improve t
On 1/22/21 4:52 AM, Julien Grall wrote:
> Hi Boris,
>
> On 20/01/2021 22:49, Boris Ostrovsky wrote:
>> This option allows guest administrator specify what should happen when
>> guest accesses an MSR which is not explicitly emulated by the hypervisor.
>>
>> Signed-off-by: Boris Ostrovsky
>> ---
On 22/01/2021 18:28, Boris Ostrovsky wrote:
On 1/22/21 4:52 AM, Julien Grall wrote:
Hi Boris,
On 20/01/2021 22:49, Boris Ostrovsky wrote:
This option allows guest administrator specify what should happen when
guest accesses an MSR which is not explicitly emulated by the hypervisor.
Signe
On 1/22/21 4:56 AM, Julien Grall wrote:
> Hi Boris,
>
> On 20/01/2021 22:49, Boris Ostrovsky wrote:
>> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
>> index 19168572fd3e..1f2abf6679d7 100644
>> --- a/tools/libs/light/libxl_dom.c
>> +++ b/tools/libs/light/libxl_dom.c
On 1/22/21 1:33 PM, Julien Grall wrote:
>
> Thanks. In which case, I would suggest to move the definition of ignore_msrs
> in the idle to an x86 specific structure. Maybe "arch_x86"?
I did consider this but left it in common area since there are already a bunch
of fields there that are x86
On 1/22/21 6:51 AM, Jan Beulich wrote:
> On 20.01.2021 23:49, Boris Ostrovsky wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -295,7 +295,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> }
>>
>> /* Fallthrough. */
>> -case 0x40
On 1/22/21 7:51 AM, Jan Beulich wrote:
> On 20.01.2021 23:49, Boris Ostrovsky wrote:
>
>> +
>> +/*
>> + * Accesses to unimplemented MSRs as part of emulation of instructions
>> + * other than guest's RDMSR/WRMSR should never succeed.
>> + */
>> +if ( !is_guest_msr_access )
Hi,
At 17:31 +0100 on 22 Jan (1611336662), Jan Beulich wrote:
> On 22.01.2021 14:11, Tim Deegan wrote:
> > At 16:10 +0100 on 14 Jan (1610640627), Jan Beulich wrote:
> >> hash_{domain,vcpu}_foreach() have a use each of literal 15. It's not
> >> clear to me what the proper replacement constant would
Any chance of getting this backported to stable?
I believe the previous attempt by CC-ing stable was not following the
correct procedure and probably rejected.
https://lkml.org/lkml/2021/1/19/543
On Wed, 20 Jan 2021 at 16:17, Arthur Borsboom wrote:
>
> This time the patch applied cleanly.
>
> Th
On 22/01/2021 18:39, Boris Ostrovsky wrote:
On 1/22/21 1:33 PM, Julien Grall wrote:
Thanks. In which case, I would suggest to move the definition of ignore_msrs in the idle
to an x86 specific structure. Maybe "arch_x86"?
I did consider this but left it in common area since there are a
flight 158560 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158560/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158550
test-amd64-amd64-xl-qemuu-win7-amd64
On Fri, Jan 22, 2021 at 10:39:28AM +0100, Jan Beulich wrote:
> On 22.01.2021 01:51, Bobby Eshleman wrote:
> > I followed with v2 feedback and attempted to convert the PE/COFF header
> > into C instead of ASM. Unfortunately, this was only possible for the
> > first part (Legacy) of the PE/COFF head
On Fri, 22 Jan 2021, Oleksandr wrote:
> On 22.01.21 13:37, Rahul Singh wrote:
>
> Hi Rahul
>
> > Add support for ARM architected SMMUv3 implementation. It is based on
> > the Linux SMMUv3 driver.
> >
> > Driver is currently supported as Tech Preview.
> >
> > Major differences with regard to Lin
flight 158580 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158580/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Fri, Jan 22, 2021 at 12:27:29PM +0100, Jan Beulich wrote:
> On 22.01.2021 01:51, Bobby Eshleman wrote:
> > export XEN_BUILD_DATE ?= $(shell LC_ALL=C date)
> > export XEN_BUILD_TIME ?= $(shell LC_ALL=C date +%T)
> > export XEN_BUILD_HOST ?= $(shell hostname)
> > +export XEN_BUIL
Em qua., 20 de jan. de 2021 às 12:13, Jürgen Groß escreveu:
>
> On 20.01.21 09:50, Jan Beulich wrote:
> > On 19.01.2021 20:36, Claudemir Todo Bom wrote:
> >> I do not have serial output on this setup, so I recorded a video with
> >> boot_delay=50 in order to be able to get all the kernel messages:
flight 158569 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Remove copy/paste error introduced by f58976544ff4 ("automation: use
test-artifacts/qemu-system-aarch64 instead of Debian's")
Fixes: f58976544ff4 ("automation: use test-artifacts/qemu-system-aarch64
instead of Debian's")
Signed-off-by: Stefano Stabellini
---
automation/scripts/qemu-alpine-arm64
On 22/01/2021 23:53, Stefano Stabellini wrote:
> Remove copy/paste error introduced by f58976544ff4 ("automation: use
> test-artifacts/qemu-system-aarch64 instead of Debian's")
>
> Fixes: f58976544ff4 ("automation: use test-artifacts/qemu-system-aarch64
> instead of Debian's")
> Signed-off-by: Ste
+ xen-devel, Roman,
On Fri, 22 Jan 2021, Jukka Kaartinen wrote:
> Hi Stefano,
> I'm Jukka Kaartinen a SW developer working on enabling hypervisors on mobile
> platforms. One of our HW that we use on development is
> Raspberry Pi 4B. I wonder if you could help me a bit :).
>
> I'm trying to enab
flight 158563 linux-5.4 real [real]
flight 158582 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158563/
http://logs.test-lab.xenproject.org/osstest/logs/158582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On Fri, Jan 22, 2021 at 4:27 PM Stefano Stabellini
wrote:
>
> + xen-devel, Roman,
>
>
> On Fri, 22 Jan 2021, Jukka Kaartinen wrote:
> > Hi Stefano,
> > I'm Jukka Kaartinen a SW developer working on enabling hypervisors on
> > mobile platforms. One of our HW that we use on development is
> > Raspb
flight 158566 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158566/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6c5801be6ef36e35f0b4ff906a4c99d68ca6f69a
baseline version:
ovmf 5b4a97bbc39ed8e7eb500
A recent thread [1] has exposed a couple of issues with our current way
of handling EXPERT.
1) It is not obvious that "Configure standard Xen features (expert
users)" is actually the famous EXPERT we keep talking about on xen-devel
2) It is not obvious when we need to enable EXPERT to get a speci
flight 158564 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 158584 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158584/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
94 matches
Mail list logo
