On Wed, Jul 22, 2020 at 10:59 AM Srinivas Bangalore wrote:
> Dear Xen experts,
>
> Would greatly appreciate some hints on how to move forward with this one…
Hi Srini,
I don't have any strong recommendations for you, but I do want to say
that I'm very happy to see you taking this project on and
flight 152097 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which are
On Wed, 22 Jul 2020, Anchal Agarwal wrote:
> On Tue, Jul 21, 2020 at 05:18:34PM -0700, Stefano Stabellini wrote:
> > On Tue, 21 Jul 2020, Boris Ostrovsky wrote:
> > > >> +static int xen_setup_pm_notifier(void)
> > > >> +{
> > > >> + if (!xen_hvm_domain())
> > > >> +
On 7/22/20 2:02 PM, Anchal Agarwal wrote:
> On Tue, Jul 21, 2020 at 05:18:34PM -0700, Stefano Stabellini wrote:
>>
>>
>>> If you are not sure what the effects are (or sure that it won't work) on
>>> ARM then I'd add IS_ENABLED(CONFIG_X86) check, i.e.
>>>
>>>
>>> if (!IS_ENABLED(CONFIG_X86) ||
On Tue, Jul 21, 2020 at 05:18:34PM -0700, Stefano Stabellini wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On Tue, 21 Jul 2020, Boris Ostrovsky wrote:
flight 152091 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/152091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 18 guest-localmigrate/x10 fail REGR. vs. 152045
flight 152121 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152121/
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
flight 152123 xen-4.14-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/152123/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirtqueued
Dear Xen experts,
Would greatly appreciate some hints on how to move forward with this one.
I have included further details on Xen diagnostics below:
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ e100
(XEN) Allocating 1:1 mappings totalling 512MB for
On 22/07/2020 18:13, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 22 July 2020 17:59
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Paul Durrant ; Andrew Cooper
; George Dunlap
; Ian Jackson ; Jan Beulich
;
Stefano Stabellini ; Wei Liu
Subject: Re:
Paul Durrant writes ("[PATCH-for-4.14] SUPPORT.md: Set version and
release/support dates"):
> From: Paul Durrant
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Stefano Stabellini
> Cc: Wei Liu
>
> -Original Message-
> From: Julien Grall
> Sent: 22 July 2020 17:59
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ;
> Stefano Stabellini ; Wei Liu
> Subject: Re: [PATCH-for-4.14] SUPPORT.md: Set
On 22/07/2020 17:55, Paul Durrant wrote:
From: Paul Durrant
Signed-off-by: Paul Durrant
Acked-by: Julien Grall
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
Cc: Wei Liu
Obviously this has my implicit
From: Paul Durrant
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
Cc: Wei Liu
Obviously this has my implicit Release-acked-by and is to be committed to
the staging-4.14 branch only.
---
From: Julien Grall
Even if we assigned pirq->arch.irq to a variable, a compile is still
allowed to read pirq->arch.irq multiple time. This means that the value
checked may be different from the value used to get the desc.
Force the compiler to only do one read access by using read_atomic().
On Tue, 21 Jul 2020, Brian Woods wrote:
> Modify the smmu driver so that it uses the iommu_fwspec helper
> functions. This means both ARM IOMMU drivers will both use the
> iommu_fwspec helper functions.
>
> Signed-off-by: Brian Woods
[...]
> @@ -1924,14 +1924,21 @@ static int
On 22.07.2020 17:15, Andrew Cooper wrote:
> * Rename nr to nr_frames. A plain 'nr' is confusing to follow in the the
>lower levels.
> * Use DIV_ROUND_UP() rather than opencoding it in several different ways
> * The hypercall input is capped at uint32_t, so there is no need for
>
On 22.07.2020 16:39, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On Thu, 2020-03-26 at 18:08 +0100, Dario Faggioli wrote:
> Code is a bit involved, and it is not easy to tell that min_rqd,
> inside
> csched2_res_pick() is actually pointing to a runqueue, when it is
> dereferenced.
>
> Add a comment and an ASSERT() for that.
>
> Suggested-by: Jan Beulich
>
On Tue, 2020-07-21 at 14:08 +0200, Jan Beulich wrote:
> On 28.05.2020 23:29, Dario Faggioli wrote:
> > Dario Faggioli (7):
> > xen: credit2: factor cpu to runqueue matching in a function
> > xen: credit2: factor runqueue initialization in its own
> > function.
> > xen: cpupool:
On Wed, Jul 22, 2020 at 04:11:21PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[osstest PATCH] dom0pvh: assign 1GB of memory to PVH
> dom0"):
> > Current tests use 512MB of memory for dom0, but that's too low for a
> > PVH dom0 on some hosts and will cause errors because memory is
> >
flight 152094 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
* Rename nr to nr_frames. A plain 'nr' is confusing to follow in the the
lower levels.
* Use DIV_ROUND_UP() rather than opencoding it in several different ways
* The hypercall input is capped at uint32_t, so there is no need for
nr_frames to be unsigned long in the lower levels.
No
Roger Pau Monne writes ("[osstest PATCH] dom0pvh: assign 1GB of memory to PVH
dom0"):
> Current tests use 512MB of memory for dom0, but that's too low for a
> PVH dom0 on some hosts and will cause errors because memory is
> ballooned out in order to obtain physical memory ranges to map foreign
>
Current tests use 512MB of memory for dom0, but that's too low for a
PVH dom0 on some hosts and will cause errors because memory is
ballooned out in order to obtain physical memory ranges to map foreign
pages.
Using ballooned out pages for foreign mappings also doesn't seem to
work properly with
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
These almost certainly aren't all the style issues, but the end result is
certainly far more consistent.
---
xen/arch/x86/hvm/svm/intr.c | 19 ++-
xen/arch/x86/hvm/svm/nestedsvm.c |
In "Executive: Use index for report__find_test" we changed an EXISTS
subquery into a JOIN.
Now, the condition r.flight=f.flight is redundant because this is the
join column (from USING).
No functional change.
CC: George Dunlap
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 1 -
1 file
George Dunlap writes ("Re: [OSSTEST PATCH 05/14] sg-report-flight: Use WITH to
use best index use for $flightsq"):
> On Jul 21, 2020, at 7:41 PM, Ian Jackson wrote:
> > After:
> > WITH sub AS (
> >SELECT DISTINCT flight, blessing
> > FROM flights
> > JOIN
George Dunlap writes ("Re: [OSSTEST PATCH 04/14] sg-report-flight: Ask the db
for flights of interest"):
> > On Jul 21, 2020, at 7:41 PM, Ian Jackson wrote:
> > Example query before (from the Perl DBI trace):
> >
> > SELECT * FROM (
> >SELECT flight, blessing FROM flights
...
> >
George Dunlap writes ("Re: [OSSTEST PATCH 08/14] Executive: Use index for
report__find_test"):
> > On Jul 21, 2020, at 7:41 PM, Ian Jackson wrote:
> > Example query before (from the Perl DBI trace):
...
> So this says:
>
> Get me all the columns
> for the highest-numbered flight
> Where:
>
> On Jul 21, 2020, at 7:41 PM, Ian Jackson wrote:
>
> While we're here, convert this EXISTS subquery to a JOIN.
>
> Perf: runtime of my test case now ~200-300s.
>
> Example query before (from the Perl DBI trace):
>
> SELECT * FROM (
>SELECT DISTINCT flight, blessing
>
> On Jul 21, 2020, at 7:41 PM, Ian Jackson wrote:
>
> Specifically, we narrow the initial query to flights which have at
> least some job with the built_revision_foo we are looking for.
>
> This condition is strictly broader than that implemented inside the
> flight search loop, so there is
flight 152081 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152081/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt 13
On 22.07.2020 12:10, Andrew Cooper wrote:
> On 22/07/2020 10:16, Jan Beulich wrote:
>> On 21.07.2020 19:22, Andrew Cooper wrote:
>>> ... to simplify the default cases.
>>>
>>> There are multiple errors with the handling of these three MSRs, but they
>>> are
>>> deliberately not addressed this
flight 152076 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152076/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
151065
Roger Pau Monne writes ("[osstest PATCH] freebsd: remove freebsd- hostflags
request from guest tests"):
> Guest tests shouldn't care about the capabilities or firmware of the
> underlying hosts, so drop the request of specific freebsd-
> hostflags for FreeBSD guest tests.
>
> While there request
On Wed, Jul 22, 2020 at 12:17:26PM +0100, Julien Grall wrote:
>
>
> On 22/07/2020 12:10, Roger Pau Monné wrote:
> > On Wed, Jul 22, 2020 at 11:47:18AM +0100, Julien Grall wrote:
> > > >
> > > > You can still use the map-on-fault behaviour as above, but I would
> > > > recommend that you try to
> On Jul 21, 2020, at 7:41 PM, Ian Jackson wrote:
>
> After we refactor this query then we can enable the index use.
> (Both of these things together in this commit because I haven't perf
> tested the version with just the refactoring.)
>
> (We have provided an index that can answer this
This is a weird variable to have in the first place. The only user of it is
XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts
run with this are shebang sh anyway, so don't need bash in the first place.
Make the mkflask.sh and mkaccess_vector.sh scripts executable,
On 22/07/2020 12:10, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 11:47:18AM +0100, Julien Grall wrote:
You can still use the map-on-fault behaviour as above, but I would
recommend that you try to limit the number of hypercalls issued.
Having to issue a single hypercall for each page
On Wed, Jul 22, 2020 at 11:47:18AM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 22/07/2020 09:21, Roger Pau Monné wrote:
> > On Tue, Jul 21, 2020 at 10:12:40PM +0100, Julien Grall wrote:
> > > Hi Oleksandr,
> > >
> > > On 21/07/2020 19:16, Oleksandr wrote:
> > > >
> > > > On 21.07.20 17:27,
flight 152088 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152088/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9132a31b9c8381197eee75eb66c809182b264110
baseline version:
ovmf
Both the read and write side have commonalities which can be abstracted away.
This also allows for additional safety in release builds, and slightly more
helpful diagnostics in debug builds.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
I'm not a massive
Hi Roger,
On 22/07/2020 09:21, Roger Pau Monné wrote:
On Tue, Jul 21, 2020 at 10:12:40PM +0100, Julien Grall wrote:
Hi Oleksandr,
On 21/07/2020 19:16, Oleksandr wrote:
On 21.07.20 17:27, Julien Grall wrote:
On a similar topic, I am a bit surprised you didn't encounter memory
exhaustion
flight 152103 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152103/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f3885e8c3ceaef101e466466e879e97103ecce18
baseline version:
xen
... rather than from the default clauses of the PV and HVM MSR handlers.
This means that we no longer take the vmce lock for any unknown MSR, and
accesses to architectural MCE banks outside of the subset implemented for the
guest no longer fall further through the unknown MSR path.
With the vmce
On 22/07/2020 10:16, Jan Beulich wrote:
> On 21.07.2020 19:22, Andrew Cooper wrote:
>> ... to simplify the default cases.
>>
>> There are multiple errors with the handling of these three MSRs, but they are
>> deliberately not addressed this point.
>>
>> This removes the dance converting -1/0/1
On 22/07/2020 10:34, Jan Beulich wrote:
> On 22.07.2020 11:26, Roger Pau Monné wrote:
>> On Tue, Jul 21, 2020 at 06:22:08PM +0100, Andrew Cooper wrote:
>>> @@ -2085,6 +2091,22 @@ static int svm_msr_write_intercept(unsigned int msr,
>>> uint64_t msr_content)
>>> goto gpf;
>>>
On 22.07.20 11:30, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 11:23:20AM +0200, Jürgen Groß wrote:
On 22.07.20 11:02, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 10:59:48AM +0200, Jürgen Groß wrote:
On 22.07.20 10:38, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 12:37:46AM +,
On 22.07.2020 11:26, Roger Pau Monné wrote:
> On Tue, Jul 21, 2020 at 06:22:08PM +0100, Andrew Cooper wrote:
>> @@ -2085,6 +2091,22 @@ static int svm_msr_write_intercept(unsigned int msr,
>> uint64_t msr_content)
>> goto gpf;
>> break;
>>
>> +case MSR_K8_VM_CR:
>> +
On Wed, Jul 22, 2020 at 11:23:20AM +0200, Jürgen Groß wrote:
> On 22.07.20 11:02, Roger Pau Monné wrote:
> > On Wed, Jul 22, 2020 at 10:59:48AM +0200, Jürgen Groß wrote:
> > > On 22.07.20 10:38, Roger Pau Monné wrote:
> > > > On Wed, Jul 22, 2020 at 12:37:46AM +, osstest service owner wrote:
>
On Tue, Jul 21, 2020 at 06:22:08PM +0100, Andrew Cooper wrote:
> ... to simplify the default cases.
>
> There are multiple errors with the handling of these three MSRs, but they are
> deliberately not addressed this point.
^ at
>
> This removes the dance converting
On 22.07.20 11:02, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 10:59:48AM +0200, Jürgen Groß wrote:
On 22.07.20 10:38, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 12:37:46AM +, osstest service owner wrote:
flight 152067 xen-unstable real [real]
On 21.07.2020 19:22, Andrew Cooper wrote:
> ... to simplify the default cases.
>
> There are multiple errors with the handling of these three MSRs, but they are
> deliberately not addressed this point.
>
> This removes the dance converting -1/0/1 into X86EMUL_*, allowing for the
> removal of the
Hi,
On 02/07/2020 19:22, Anchal Agarwal wrote:
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 2521d6a306cd..9fa8a4082d68 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -41,6 +41,8 @@ u64 xen_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
On Wed, Jul 22, 2020 at 10:59:48AM +0200, Jürgen Groß wrote:
> On 22.07.20 10:38, Roger Pau Monné wrote:
> > On Wed, Jul 22, 2020 at 12:37:46AM +, osstest service owner wrote:
> > > flight 152067 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/152067/
> > >
> >
On 22.07.20 10:38, Roger Pau Monné wrote:
On Wed, Jul 22, 2020 at 12:37:46AM +, osstest service owner wrote:
flight 152067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
All,
better late than never, I am pleased to announce the release of Xen 4.11.4.
This has been available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11
(tag RELEASE-4.11.4) or from the XenProject download page
On Wed, Jul 22, 2020 at 12:37:46AM +, osstest service owner wrote:
> flight 152067 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/152067/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
On 22.07.2020 02:37, osstest service owner wrote:
> flight 152067 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/152067/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
On Tue, Jul 21, 2020 at 07:55:09PM +, Anchal Agarwal wrote:
> On Tue, Jul 21, 2020 at 10:30:18AM +0200, Roger Pau Monné wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the
Xen accelerator requires specific changes to a machine to be able
to use it. See for example the 'Xen PC' machine configure its PCI
bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine
declared. This code was probably added while introducing the Q35
machine, based on the existing PC
On Tue, Jul 21, 2020 at 10:12:40PM +0100, Julien Grall wrote:
> Hi Oleksandr,
>
> On 21/07/2020 19:16, Oleksandr wrote:
> >
> > On 21.07.20 17:27, Julien Grall wrote:
> > > On a similar topic, I am a bit surprised you didn't encounter memory
> > > exhaustion when trying to use virtio. Because on
If the TSC frequency is known from the pvclock page,
the TSC frequency does not need to be recalibrated.
We can avoid recalibration by setting X86_FEATURE_TSC_KNOWN_FREQ.
Signed-off-by: Hayato Ohhashi
---
arch/x86/xen/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git
There's a potential race in xennet_remove(); this is what the driver is
doing upon unregistering a network device:
1. state = read bus state
2. if state is not "Closed":
3.request to set state to "Closing"
4.wait for state to be set to "Closing"
5.request to set state to
flight 152070 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
66 matches
Mail list logo
