On 02.10.20 08:20, Jan Beulich wrote:
On 02.10.2020 06:50, Jürgen Groß wrote:
On 01.10.20 18:38, Bertrand Marquis wrote:
Hi Juergen,
On 14 Sep 2020, at 11:58, Bertrand Marquis wrote:
On 12 Sep 2020, at 14:08, Juergen Gross wrote:
Making getBridge() static triggered a build error with s
On Thu, Oct 1, 2020 at 7:38 AM Bertrand Marquis
wrote:
>
> Hi George,
>
> + Christopher Clark to have his view on what to put for Yocto.
>
> > On 30 Sep 2020, at 13:57, George Dunlap wrote:
> >
> > Define a specific criteria for how we determine what tools and
> > libraries to be compatible with.
On 02.10.2020 06:50, Jürgen Groß wrote:
> On 01.10.20 18:38, Bertrand Marquis wrote:
>> Hi Juergen,
>>
>>> On 14 Sep 2020, at 11:58, Bertrand Marquis wrote:
>>>
>>>
>>>
On 12 Sep 2020, at 14:08, Juergen Gross wrote:
Making getBridge() static triggered a build error with some gcc ve
flight 155173 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 154350
tes
On 01.10.2020 18:21, Julien Grall wrote:
> On 30/09/2020 11:16, Jan Beulich wrote:
>> On 30.09.2020 10:52, Paul Durrant wrote:
>>> Looking again, given that both send_guest_vcpu_virq() and
>>> send_guest_global_virq() (rightly) hold the evtchn lock before
>>> calling evtchn_port_set_pending() I thi
flight 155193 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155193/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 155287 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On 01.10.20 18:38, Bertrand Marquis wrote:
Hi Juergen,
On 14 Sep 2020, at 11:58, Bertrand Marquis wrote:
On 12 Sep 2020, at 14:08, Juergen Gross wrote:
Making getBridge() static triggered a build error with some gcc versions:
error: 'strncpy' output may be truncated copying 15 bytes fro
On 01.10.20 18:43, Bertrand Marquis wrote:
Hi,
On 1 Oct 2020, at 17:29, Bertrand Marquis wrote:
Hi Jan,
On 1 Oct 2020, at 17:03, Jan Beulich wrote:
On 10.09.2020 14:09, Jan Beulich wrote:
While looking at what it would take to move around libelf/
in the hypervisor subtree, I've run into
flight 155152 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155152/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 154601
test-amd64-amd
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job test-amd64-amd64-libvirt
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git
flight 155271 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155271/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
flight 155140 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 15171
QEMU without VNC support (configure --disable-vnc) will return an error
when VNC is queried over QMP since it does not recognize the QMP
command. This will cause libxl to fail starting the domain even if VNC
is not enabled. Therefore only query QEMU for VNC support when using
VNC, so a VNC-less Q
On Mon, 28 Sep 2020, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> Don't hardcode the lookup start level of the page table walk to 1
> and instead match the one used in P2M. This should fix scenarios
> involving SMMU where the start level is different than 1.
>
> Signed-off-by: Laur
flight 155262 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155262/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On Thu, 1 Oct 2020, George Dunlap wrote:
> > On Sep 30, 2020, at 9:23 PM, Stefano Stabellini
> > wrote:
> >
> > On Wed, 30 Sep 2020, George Dunlap wrote:
> >> Define a specific criteria for how we determine what tools and
> >> libraries to be compatible with. This will clarify issues such as,
>
flight 155246 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
flight 155136 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155136/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 155049
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
flight 155132 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 154358
test-amd64-amd
On Thu, Oct 1, 2020 at 12:05 PM Julien Grall wrote:
>
> Hi,
>
> On 24/09/2020 11:53, Jan Beulich wrote:
> > xmalloc() & Co may not be called with IRQs off, or else check_lock()
> > will have its assertion trigger about locks getting acquired
> > inconsistently. Re-arranging the locking in evtchn_s
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-xsm
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.o
Hi,
> On 1 Oct 2020, at 17:29, Bertrand Marquis wrote:
>
> Hi Jan,
>
>> On 1 Oct 2020, at 17:03, Jan Beulich wrote:
>>
>> On 10.09.2020 14:09, Jan Beulich wrote:
>>> While looking at what it would take to move around libelf/
>>> in the hypervisor subtree, I've run into this rule, which I
>>>
Hi Juergen,
> On 14 Sep 2020, at 11:58, Bertrand Marquis wrote:
>
>
>
>> On 12 Sep 2020, at 14:08, Juergen Gross wrote:
>>
>> Making getBridge() static triggered a build error with some gcc versions:
>>
>> error: 'strncpy' output may be truncated copying 15 bytes from a string of
>> length
Hi Jan,
> On 1 Oct 2020, at 17:03, Jan Beulich wrote:
>
> On 10.09.2020 14:09, Jan Beulich wrote:
>> While looking at what it would take to move around libelf/
>> in the hypervisor subtree, I've run into this rule, which I
>> think can do with a few improvements and some simplification.
>>
>> 1
Right now we have a situation where these can't all be made to work
because because some older Xen branches are hard to make work on
current Debian stable, and we have some hardware (which we have tagged
as specific "platforms") which doesn't work with oldstable.
This seems like a general problem,
Now, a job can specify that lack of a suitable host should be treated
as a plain test failure (ie, subject to the usual regression analysis)
rather than as an infrastructure or configuration problem.
This will be useful for some tests which don't work in some branches
because of lack of suitable h
Set MF_SIMULATE_PLATFORMS to a suitable value if it is
not *set*. (Distinguishing unset from set to empty.)
I have verified that this, plus the preceding commits to
cri-getplatforms, produces no change in the output of
MF_SIMULATE_PLATFORMS='' OSSTEST_CONFIG=standalone-config-example eatmydata
This is to be expanded by the shell, using eval, so that it can refer
to $xenarch, $suite and $blessing.
No functional change if this variable is unset, or empty. If it is
set to a single space, cri-getplatforms produces no output (as it does
anyway in standalone mode).
Signed-off-by: Ian Jackso
$onhost can be undef too
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 80e70070..a0d9f81e 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -1283,7 +1283,8
These two mkdir calls could fail if
standalone-generate-dump-flight-runvars is run without a log
directory, because they were not concurrency-correct.
mkdir -p should fix that.
Signed-off-by: Ian Jackson
---
standalone | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/
No functional change. This will be useful in a moment.
Signed-off-by: Ian Jackson
---
cri-getplatforms | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/cri-getplatforms b/cri-getplatforms
index 2b8cee0b..1f206908 100755
--- a/cri-getplatforms
+++ b/cri-getplatforms
@@ -17,
If the test script exits nonzero but after setting the step status to
'fail', we can leave it that way. This is particularly relevant if
the iffail in the job spec says 'broken' or something. After this
change, a step can decide to override that.
An alternative would be to have the step script e
Hi Jan,
On 30/09/2020 11:16, Jan Beulich wrote:
On 30.09.2020 10:52, Paul Durrant wrote:
Looking again, given that both send_guest_vcpu_virq() and
send_guest_global_virq() (rightly) hold the evtchn lock before
calling evtchn_port_set_pending() I think you could do away with
the virq lock by add
Hi Juergen,
> On 25 Sep 2020, at 07:20, Juergen Gross wrote:
>
> Don't include struct elf_dom_parms in struct xc_dom_image, but rather
> use a pointer to reference it. Together with adding accessor functions
> for the externally needed elements this enables to drop including the
> Xen private he
Hi,
On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger about locks getting acquired
inconsistently. Re-arranging the locking in evtchn_send() doesn't seem
very reasonable, especially since the per-channel l
On 10.09.2020 14:09, Jan Beulich wrote:
> While looking at what it would take to move around libelf/
> in the hypervisor subtree, I've run into this rule, which I
> think can do with a few improvements and some simplification.
>
> 1: adjust population of acpi/
> 2: fix (drop) dependencies of when
Hi,
On 28/09/2020 12:00, Jan Beulich wrote:
The general expectation is that there are only a few open ports left
when a domain asks its event channel configuration to be reset.
Similarly on average half a bucket worth of event channels can be
expected to be inactive. Try to avoid iterating over
On Wed, Sep 30, 2020 at 01:57:36PM +0100, George Dunlap wrote:
> Define a specific criteria for how we determine what tools and
> libraries to be compatible with. This will clarify issues such as,
> "Should we continue to support Python 2.4" moving forward.
>
> Note that CentOS 7 is set to stop r
Hi Stefano,
On 01/10/2020 00:40, Stefano Stabellini wrote:
On Sat, 26 Sep 2020, Julien Grall wrote:
I have a small suggestion for improvement that could be done on commit:
given that bootinfo is actually used on EFI systems (granted, not
bootinfo.reserved_mem but bootinfo.mem, see
xen/arch/arm/e
On 24/09/2020 14:10, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and bump the version.
>
> This patch implements version 4 of the migration stream by adding the code
> necessary to save and restore DOMAIN_CONTEXT records, and removing the code
> to save the SHARED_INFO and TSC_INFO records (a
Hi Stefano,
On 01/10/2020 01:30, Stefano Stabellini wrote:
On Sat, 26 Sep 2020, Julien Grall wrote:
From: Julien Grall
Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()" enforced that each set_fixmap() should be
paired with a clear_fixmap(). Any failure
Hi Stefano,
On 01/10/2020 01:06, Stefano Stabellini wrote:
On Sat, 26 Sep 2020, Julien Grall wrote:
From: Julien Grall
The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
Currently, the former are still co
> On Oct 1, 2020, at 1:58 PM, Andrew Cooper wrote:
>
> On 30/09/2020 13:57, George Dunlap wrote:
>> Define a specific criteria for how we determine what tools and
>> libraries to be compatible with. This will clarify issues such as,
>> "Should we continue to support Python 2.4" moving forward.
flight 155225 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On 19.08.2020 18:52, Don Slutz wrote:
> This adds synchronization of the 6 vcpu registers (only 32bits of
> them) that QEMU's vmport.c and vmmouse.c needs between Xen and QEMU.
> This is how VMware defined the use of these registers.
>
> This is to avoid a 2nd and 3rd exchange between QEMU and Xen
Hi George,
+ Christopher Clark to have his view on what to put for Yocto.
> On 30 Sep 2020, at 13:57, George Dunlap wrote:
>
> Define a specific criteria for how we determine what tools and
> libraries to be compatible with. This will clarify issues such as,
> "Should we continue to support Py
Yan,
On Thu, Oct 01 2020 at 09:39, Zi Yan wrote:
> On 1 Oct 2020, at 4:22, Thomas Gleixner wrote:
>> Can you please test:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/irq
>>
>> which contains fixes and if it still crashes provide the dmesg of it.
>
> My system boots witho
On 1 Oct 2020, at 4:22, Thomas Gleixner wrote:
> Yan,
>
> On Wed, Sep 30 2020 at 21:29, Zi Yan wrote:
>> I am running linux-next on my Dell R630 and the system crashed at boot
>> time. I bisected linux-next and got to your commit:
>>
>> x86/msi: Consolidate MSI allocation
>>
>> The crash log i
flight 155125 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 6 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 19.08.2020 18:51, Don Slutz wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -504,6 +504,8 @@ int arch_sanitise_domain_config(struct
> xen_domctl_createdomain *config)
>
> static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> {
> +uint32_t all
On 30/09/2020 13:57, George Dunlap wrote:
> Define a specific criteria for how we determine what tools and
> libraries to be compatible with. This will clarify issues such as,
> "Should we continue to support Python 2.4" moving forward.
Luckily that one is settled. Arguably a better option might
>>> Also, wrt KASLR stuff, that issue is still seen sometimes but I haven't
>>> had
>>> bandwidth to dive deep into the issue and fix it.
So what's the plan there? You first mentioned this issue early this year
and judged by your response it is not clear whether you will e
On 01/10/2020 13:31, Marek Marczykowski-Górecki wrote:
> On Thu, Oct 01, 2020 at 01:59:32PM +0200, Jan Beulich wrote:
>> On 01.10.2020 03:12, Marek Marczykowski-Górecki wrote:
>>> After patching the previous issue ("x86/S3: Fix Shadow Stack resume
>>> path") I still encounter issues resume from S3.
On Thu, Oct 01, 2020 at 01:59:32PM +0200, Jan Beulich wrote:
> On 01.10.2020 03:12, Marek Marczykowski-Górecki wrote:
> > After patching the previous issue ("x86/S3: Fix Shadow Stack resume
> > path") I still encounter issues resume from S3.
> > Since I had it working on Xen 4.13 on this particular
flight 155126 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155126/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
test-amd64-i386-xl-qemut-debianhvm-i3
On 01.10.2020 14:00, Marek Marczykowski-Górecki wrote:
> On Thu, Oct 01, 2020 at 03:12:47AM +0200, Marek Marczykowski-Górecki wrote:
>> After patching the previous issue ("x86/S3: Fix Shadow Stack resume
>> path") I still encounter issues resume from S3.
>> Since I had it working on Xen 4.13 on thi
On Thu, Oct 01, 2020 at 03:12:47AM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
>
> After patching the previous issue ("x86/S3: Fix Shadow Stack resume
> path") I still encounter issues resume from S3.
> Since I had it working on Xen 4.13 on this particular hardware (Thinkpad
> P52), I bisected
On 01.10.2020 03:12, Marek Marczykowski-Górecki wrote:
> After patching the previous issue ("x86/S3: Fix Shadow Stack resume
> path") I still encounter issues resume from S3.
> Since I had it working on Xen 4.13 on this particular hardware (Thinkpad
> P52), I bisected it and got this:
>
> commit 4
On 01.10.2020 13:44, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
xen/common/domain.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 8cfa2e0b6b..c4a480fa14 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -310,6 +310,12 @@ static int sanitise_domain_config
On Thu, Oct 01, 2020 at 09:15:00AM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> Currently a single watch on /local/domain/X/backend is registered by each
> QEMU process running in service domain X (where X is usually 0). The purpose
> of this watch is to ensure that QEMU is notified when t
flight 155213 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On Fri, Sep 25, 2020 at 08:20:28AM +0200, Juergen Gross wrote:
> This series fixes builds of libxenguest users outside the Xen build
> system and it cleans up the xenguest.h header merging xenctrl_dom.h
> into it.
>
> Juergen Gross (3):
> tools/libs: merge xenctrl_dom.h into xenguest.h
> tools
On Wed, Sep 30, 2020 at 02:42:48PM +0100, Andrew Cooper wrote:
> Nested virt is still experimental, and requires explicitly opting in to at
> domain create time. The VMX/SVM features should not be visible by default.
>
> Also correct them from all HVM guests, to just HAP-enabled guests. This has
On 01/10/2020 11:23, Jan Beulich wrote:
> On 30.09.2020 15:42, Andrew Cooper wrote:
>> @@ -667,6 +668,12 @@ int arch_sanitise_domain_config(struct
>> xen_domctl_createdomain *config)
>> */
>> config->flags |= XEN_DOMCTL_CDF_oos_off;
>>
>> +if ( nested_virt && !hap )
>> +
On Wed, Sep 30, 2020 at 02:42:47PM +0100, Andrew Cooper wrote:
> Previously, migration was reordered so the CPUID data was available before
> register state. nestedhvm_enabled() has recently been made accurate for the
> entire lifetime of the domain.
>
> Therefore, we can drop the bodge in hvm_cr
On Wed, Sep 30, 2020 at 02:42:46PM +0100, Andrew Cooper wrote:
> The sole caller has been removed.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
On Wed, Sep 30, 2020 at 02:42:45PM +0100, Andrew Cooper wrote:
> With XEN_DOMCTL_CDF_nested_virt now passed properly to domain_create(),
> reimplement nestedhvm_enabled() to use the property which is fixed for the
> lifetime of the domain.
>
> This makes the call to nestedhvm_vcpu_initialise() fro
On Wed, Sep 30, 2020 at 02:42:44PM +0100, Andrew Cooper wrote:
> Nested Virt is the final special case in legacy CPUID handling. Pass the
> (poorly named) nested_hvm setting down into xc_cpuid_apply_policy() to break
> the semantic dependency on HVM_PARAM_NESTEDHVM.
>
> No functional change.
>
>
On Wed, Sep 30, 2020 at 02:42:43PM +0100, Andrew Cooper wrote:
> Like other major areas of functionality, nested virt (or not) needs to be
> known at domain creation time for sensible CPUID handling, and wants to be
> known this early for sensible infrastructure handling in Xen.
>
> Introduce XEN_
On Wed, Sep 30, 2020 at 02:42:42PM +0100, Andrew Cooper wrote:
> Introduce some local variables to make the resulting logic easier to follow.
> Join the two IOMMU checks in sanitise_domain_config(). Tweak some of the
> terminology for better accuracy.
>
> No functional change.
>
> Signed-off-by:
On Wed, Sep 30, 2020 at 02:42:46PM +0100, Andrew Cooper wrote:
> The sole caller has been removed.
>
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
Thanks, Roger.
On Wed, Sep 30, 2020 at 02:42:41PM +0100, Andrew Cooper wrote:
> The use of the ternary operator serves only to obfuscate the code. Rewrite it
> in more simple terms, avoiding the need to conditionally OR zero into the
> flags.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
On Wed, Sep 30, 2020 at 02:42:45PM +0100, Andrew Cooper wrote:
> With XEN_DOMCTL_CDF_nested_virt now passed properly to domain_create(),
> reimplement nestedhvm_enabled() to use the property which is fixed for the
> lifetime of the domain.
>
> This makes the call to nestedhvm_vcpu_initialise() fro
On Fri, Aug 28, 2020 at 05:07:47PM +0200, Juergen Gross wrote:
> Move the libxlutil source to tools/libs/util and delete tools/libxl.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
On Mon, Sep 07, 2020 at 06:16:32PM +0200, Jürgen Groß wrote:
> On 07.09.20 17:55, Wei Liu wrote:
> > On Fri, Aug 28, 2020 at 05:07:45PM +0200, Juergen Gross wrote:
> > > Rename *_libxlutil make variables to *_libxenutil in order to avoid
> > > nasty indirections when moving libxlutil under the tool
On Sat, Aug 29, 2020 at 06:38:40AM +0200, Jürgen Groß wrote:
> On 28.08.20 18:00, Wei Liu wrote:
> > On Fri, Aug 28, 2020 at 05:07:46PM +0200, Juergen Gross wrote:
> > > libxlutil doesn't follow the standard name pattern of all other Xen
> > > libraries, so add another make variable which can be us
On 30.09.20 17:46, Wei Liu wrote:
On Wed, Sep 23, 2020 at 08:45:40AM +0200, Juergen Gross wrote:
Instead of creating the xenstore-stubdom domain first and parsing the
kernel later do it the other way round. This enables to probe for the
domain type supported by the xenstore-stubdom and to suppor
On 30.09.2020 15:42, Andrew Cooper wrote:
> @@ -667,6 +668,12 @@ int arch_sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> */
> config->flags |= XEN_DOMCTL_CDF_oos_off;
>
> +if ( nested_virt && !hap )
> +{
> +dprintk(XENLOG_INFO, "Nested virt
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-amd64-amd64-xl-qemut-debianhvm-i386-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tre
On Wed, Sep 30, 2020 at 02:42:44PM +0100, Andrew Cooper wrote:
> Nested Virt is the final special case in legacy CPUID handling. Pass the
> (poorly named) nested_hvm setting down into xc_cpuid_apply_policy() to break
> the semantic dependency on HVM_PARAM_NESTEDHVM.
>
> No functional change.
>
>
> On Oct 1, 2020, at 10:06 AM, Anastasiia Lukianenko
> wrote:
>
> Hi,
>
> On Wed, 2020-09-30 at 10:24 +, George Dunlap wrote:
>>> On Sep 30, 2020, at 10:57 AM, Jan Beulich
>>> wrote:
>>>
>>> On 30.09.2020 11:18, Anastasiia Lukianenko wrote:
I would like to know your opinion on the
On Wed, Sep 30, 2020 at 02:42:43PM +0100, Andrew Cooper wrote:
> Like other major areas of functionality, nested virt (or not) needs to be
> known at domain creation time for sensible CPUID handling, and wants to be
> known this early for sensible infrastructure handling in Xen.
>
> Introduce XEN_
> On Sep 30, 2020, at 9:23 PM, Stefano Stabellini
> wrote:
>
> On Wed, 30 Sep 2020, George Dunlap wrote:
>> Define a specific criteria for how we determine what tools and
>> libraries to be compatible with. This will clarify issues such as,
>> "Should we continue to support Python 2.4" moving
On Wed, Sep 30, 2020 at 02:42:42PM +0100, Andrew Cooper wrote:
> Introduce some local variables to make the resulting logic easier to follow.
> Join the two IOMMU checks in sanitise_domain_config(). Tweak some of the
> terminology for better accuracy.
>
> No functional change.
>
> Signed-off-by:
On Tue, Sep 22, 2020 at 12:58:24PM +0200, Juergen Gross wrote:
> Fix two issues in mini-os netfront:
>
> - undo init_netfront interface change and replace it with an alternative
> - fix mini-os suspend/resume handling in netfront
>
> Juergen Gross (2):
> mini-os: netfront: retrieve netmask and
On Wed, Sep 30, 2020 at 02:42:41PM +0100, Andrew Cooper wrote:
> The use of the ternary operator serves only to obfuscate the code. Rewrite it
> in more simple terms, avoiding the need to conditionally OR zero into the
> flags.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Mig
On 01.10.2020 07:11, osstest service owner wrote:
> flight 155187 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/155187/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-libvirt
Hi,
On Wed, 2020-09-30 at 10:24 +, George Dunlap wrote:
> > On Sep 30, 2020, at 10:57 AM, Jan Beulich
> > wrote:
> >
> > On 30.09.2020 11:18, Anastasiia Lukianenko wrote:
> > > I would like to know your opinion on the following coding style
> > > cases.
> > > Which option do you think is cor
flight 155200 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On Wed, Sep 30, 2020 at 09:03:03PM -0700, Christopher Clark wrote:
> Hello
>
> Following up on a topic introduced in last month's community call,
> here are some notes on combining existing Linux guest virtio drivers
> with Argo inter-VM communication on Xen. If feasible, this would
> combine the
> -Original Message-
> From: Jan Beulich
> Sent: 01 October 2020 09:49
> To: Julien Grall
> Cc: Oleksandr ; xen-devel@lists.xenproject.org;
> p...@xen.org; 'Oleksandr
> Tyshchenko' ; 'Andrew Cooper'
> ; 'George
> Dunlap' ; 'Ian Jackson'
> ; 'Stefano Stabellini'
> ; 'Wei Liu' ; 'Roger P
On 30.09.2020 19:47, Julien Grall wrote:
> Regarding the fix itself, I am not sure what sort of synchronization we
> can do. Are you suggesting to wait for the I/O to complete? If so, how
> do we handle the case the IOREQ server died?
In simple cases retrying the entire request may be an option.
branch xen-4.12-testing
xenbranch xen-4.12-testing
job test-amd64-i386-xl-xsm
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org
flight 155113 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155113/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 154611
test-amd64-i386-li
Yan,
On Wed, Sep 30 2020 at 21:29, Zi Yan wrote:
> I am running linux-next on my Dell R630 and the system crashed at boot
> time. I bisected linux-next and got to your commit:
>
> x86/msi: Consolidate MSI allocation
>
> The crash log is below and my .config is attached.
>
> [ 11.840905] int
From: Paul Durrant
Currently a single watch on /local/domain/X/backend is registered by each
QEMU process running in service domain X (where X is usually 0). The purpose
of this watch is to ensure that QEMU is notified when the Xen toolstack
creates a new device backend area.
Such a backend area
> -Original Message-
> From: Anthony PERARD
> Sent: 30 September 2020 12:43
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Paul Durrant
> ; Jerome
> Leseinne ; Edwin Torok ;
> Stefano Stabellini
>
> Subject: Re: [PATCH] xen-bus: reduce scope of backend
Toolstack maintainers...
Ping+1
> -Original Message-
> From: Paul Durrant
> Sent: 25 September 2020 11:39
> To: xen-devel@lists.xenproject.org
> Cc: 'Paul Durrant'
> Subject: RE: [PATCH v2 0/2] fix 'xl block-detach'
>
> Ping? AFAICT this series is fully acked. Can it be committed soon?
1 - 100 of 101 matches
Mail list logo
