> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 11 February 2019 17:47
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; George Dunlap
> ; Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Jun Nakajima
> ; Kevin Tian ; Paul Durrant
>
> Subject: [PATCH
>>> On 13.02.19 at 02:17, wrote:
> On Tue, 12 Feb 2019, Jan Beulich wrote:
>> >>> On 12.02.19 at 13:01, wrote:
>> > I would particularly welcome the opinion of hypervisor maintainers on
>> > my type safety point, below.
>>
>> I agree with the requirements you put forward; I think I'd
>> prefer
On Wed, Feb 13, 2019 at 12:20:51AM -0700, Jan Beulich wrote:
On 13.02.19 at 03:30, wrote:
>> On Tue, Feb 12, 2019 at 06:55:20AM -0700, Jan Beulich wrote:
>> On 12.02.19 at 14:25, wrote:
On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
> >>> On 28.01.19 at 08:06,
>>> On 13.02.19 at 09:50, wrote:
> On Wed, Feb 13, 2019 at 12:20:51AM -0700, Jan Beulich wrote:
> On 13.02.19 at 03:30, wrote:
>>> On Tue, Feb 12, 2019 at 06:55:20AM -0700, Jan Beulich wrote:
>>> On 12.02.19 at 14:25, wrote:
> On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich
Synopsys, which owns both Coverity and Black Duck, wrote about software
supply-chain integrity for a library with almost two million downloads per week:
"EventStream, a highly popular JavaScript library, was compromised with the
addition of a third-party dependency, flatmap-stream, containing
Apologies: it is 16:00--17:00 as in the URL, etc. - I had forgotten to update
the UTC time
I would like to add an agenda item about the timing of the meeting under AOB
* Originally the meeting was held 15:00 - 16:00 and Stefano requested it to be
moved
* However, it turns out that normally key
> -Original Message-
> From: Woods, Brian [mailto:brian.wo...@amd.com]
> Sent: 12 February 2019 20:14
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Suthikulpanit, Suravee ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monne
> Subject: Re: [PATCH 1/2] amd-iommu: use a
>>> On 13.02.19 at 02:31, wrote:
> 4. NVME passthrough performance: this is improved when VMEXITs are avoided
> by using "posted interrupts" [1] available on Broadwell and later Xeon
> processors or AWS nested hypervisor "metal" [2]. For commodity x86 CPUs
> which do not have posted
flight 133223 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 132424
version
flight 133221 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133221/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
On 2/12/19 4:03 PM, Jan Beulich wrote:
On 12.02.19 at 16:32, wrote:
>> On 12/02/2019 15:26, Ian Jackson wrote:
>>>
But if we really want to have ptrdiff_t, then I think we should either
follow the uintptr_t model and use attribute((mode())), or we should
leverage the
flight 133158 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133158/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
>>> On 13.02.19 at 03:34, wrote:
> The initial focus will be to explore and document the range of possible
> use cases that are of interest to the Xen community. This will be the
> input to a design document that is crafted in conjunction with the Xen
> maintainers, to identify possible
flight 133227 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133227/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
>>> On 12.02.19 at 19:46, wrote:
> Konrad,
>
> Starting w/ v4.17, I cannot log in to GNOME w/out getting the
> following mess in dmesg and ending up back at the GDM login screen.
>
> [ 28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
> [ 31.219821] radeon :01:00.0:
>>> On 13.02.19 at 11:28, wrote:
> On 2/12/19 4:03 PM, Jan Beulich wrote:
> On 12.02.19 at 16:32, wrote:
>>> On 12/02/2019 15:26, Ian Jackson wrote:
> But if we really want to have ptrdiff_t, then I think we should either
> follow the uintptr_t model and use attribute((mode())),
Konrad, could you please review? So, I can send v5 with Hans'
comments addressed
Thank you,
Oleksandr
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
On 1/15/19 4:44 PM, Hans Verkuil wrote:
Hi Oleksandr,
Just two remaining comments:
On 1/15/19
On 2/13/19 1:31 AM, Rich Persaud wrote:
>> On Feb 11, 2019, at 05:05, Lars Kurth wrote:
>>
>> Hi all,
>>
>> we have the community call for February coming up this Wednesday. My sincere
>> apologies, that I have not asked for agenda items last week. A current
>> agenda (primarily a skeleton) is
> On Feb 4, 2019, at 13:22, Stefano Stabellini wrote:
>
> On Mon, 4 Feb 2019, Roger Pau Monné wrote:
>>> Yes, v7 was sent to address Jan and Julien's review comments in parallel
>>> with our ongoing discussion on v5 macros. v7 also provided a checkpoint
>>> for Argo testers to maximize test
> On Feb 4, 2019, at 05:07, Roger Pau Monné wrote:
>
>> On Sun, Feb 03, 2019 at 10:04:29AM -0800, Christopher Clark wrote:
>> On Thu, Jan 31, 2019 at 5:39 AM Roger Pau Monné
>> wrote:
>>
>> On Wed, Jan 30, 2019 at 08:05:30PM -0800, Christopher Clark wrote:
>>
>>> On 08.02.19 at 14:44, wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is also used for memory loads. To avoid
> speculative out-of-bound accesses, we use the array_index_nospec macro
> where applicable. However, there are also memory
On Tue, 2019-02-12 at 13:36 +, 郑 川 wrote:
> Hi, George,
>
Hi (although I'm not George :-D),
> I found Credit2 can’t reach the throughput as expected under my test
> workload, compared to Credit and CFS. It is easy to reproduce, and I
> think the problem is really exist.
> It really took me a
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git
Convert to use vm_map_pages_zero() to map range of kernel
memory to user vma.
This driver has ignored vm_pgoff. We could later "fix" these drivers
to behave according to the normal vm_pgoff offsetting simply by
removing the _zero suffix on the function name and if that causes
regressions, it
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
map->count is passed to vm_map_pages() and internal API
verify map->count against count ( count = vma_pages(vma))
for page array boundary overrun. With this count is not
needed inside gntdev_mmap() and it could be replaced
Currently, the VM_EVENT_INTERFACE_VERSION is determined at runtime, by
inspecting the corresponding field in a vm_event_request. This helper
opcode will query the hypervisor supported version before the vm_event
related structures and layout are set-up.
Signed-off-by: Petre Pircalabu
---
flight 133160 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133160/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Wed, Feb 13, 2019 at 5:34 AM Jan Beulich wrote:
>
> >>> On 12.02.19 at 19:46, wrote:
> > Konrad,
> >
> > Starting w/ v4.17, I cannot log in to GNOME w/out getting the
> > following mess in dmesg and ending up back at the GDM login screen.
> >
> > [ 28.554259] radeon_dp_aux_transfer_native:
>>> On 13.02.19 at 15:10, wrote:
> On Wed, Feb 13, 2019 at 5:34 AM Jan Beulich wrote:
>>
>> >>> On 12.02.19 at 19:46, wrote:
>> > Konrad,
>> >
>> > Starting w/ v4.17, I cannot log in to GNOME w/out getting the
>> > following mess in dmesg and ending up back at the GDM login screen.
>> >
>> > [
flight 133229 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133229/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
Apologies if you get multiple copies of this but I seem to be having problems
sending to the list.
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 13 February 2019 16:03
> To: Paul Durrant
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger
>>> On 13.02.19 at 17:00, wrote:
> On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
>> >>> On 13.02.19 at 15:10, wrote:
>> > Ah, so this isn't necessarily Xen-specific but rather any paravirtual
>> > guest? That hadn't crossed my mind. Is there an easy way to find out
>> > if we're a pv
The current code uses hvm_asid_flush_vcpu() but this is insufficient for
a guest running in shadow mode, which results in guest crashes early in
boot if the 'hcall_remote_tlb_flush' is enabled.
This patch, instead of open coding a new flush algorithm, adapts the one
already used by the
The current code uses hvm_asid_flush_vcpu() but this is insufficient for
a guest running in shadow mode, which results in guest crashes early in
boot if the 'hcall_remote_tlb_flush' is enabled.
This patch, instead of open coding a new flush algorithm, adapts the one
already used by the
On Wed, 2019-02-13 at 08:27 -0700, Jan Beulich wrote:
> > > > On 13.02.19 at 14:25, wrote:
> >
> > @@ -592,6 +592,19 @@ int vm_event_domctl(struct domain *d, struct
> > xen_domctl_vm_event_op *vec,
> > {
> > int rc;
> >
> > +if ( vec->op == XEN_VM_EVENT_GET_INTERFACE_VERSION )
> > +
On 13/02/2019 19:38, Michael Labriola wrote:
> On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
> wrote:
>>
>> On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk
>> wrote:
>>>
>>> On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote:
>>> On 13.02.19 at 17:00, wrote:
> On Wed,
flight 133236 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133236/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
flight 133203 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133203/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a35dd723bbf9333a11f6397dac77f1a5dadd3c5
baseline version:
ovmf
From: Konrad Rzeszutek Wilk
This was submitted in 2015 here
https://marc.info/?l=linux-kernel=142807132515973=2
and has been included in Fedora builds ever since. No issues have been
reported with the patch.
P.
8<
There is no need for this at all. Worst it means that if
the guest
flight 133199 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133199/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 133237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133237/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
On 14/02/2019 01:11, Andrew Cooper wrote:
> On 13/02/2019 21:08, Michael Labriola wrote:
>> On Wed, Feb 13, 2019 at 3:21 PM Andrew Cooper
>> wrote:
>>> On 13/02/2019 20:15, Michael Labriola wrote:
On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk
wrote:
> On Wed, Feb 13, 2019
flight 133198 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133198/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 133191 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 13/02/2019 21:08, Michael Labriola wrote:
> On Wed, Feb 13, 2019 at 3:21 PM Andrew Cooper
> wrote:
>> On 13/02/2019 20:15, Michael Labriola wrote:
>>> On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk
>>> wrote:
On Wed, Feb 13, 2019 at 01:38:21PM -0500, Michael Labriola wrote:
>
flight 133241 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133241/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX is in
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 24
On Wed, Feb 13, 2019 at 04:11:10PM -0700, Jason Gunthorpe wrote:
> On Wed, Feb 13, 2019 at 03:04:51PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to be gup_flags.
>
> So now we
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Ira Weiny
In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52
On Wed, Feb 13, 2019 at 03:04:51PM -0800, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> To facilitate additional options to get_user_pages_fast() change the
> singular write parameter to be gup_flags.
So now we have:
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
On Wed, 13 Feb 2019, Jan Beulich wrote:
> >>> On 13.02.19 at 02:17, wrote:
> > On Tue, 12 Feb 2019, Jan Beulich wrote:
> >> >>> On 12.02.19 at 13:01, wrote:
> >> > I would particularly welcome the opinion of hypervisor maintainers on
> >> > my type safety point, below.
> >>
> >> I agree with
flight 133196 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
From: Ira Weiny
NOTE: This series depends on my clean up patch to remove the write parameter
from gup_fast_permitted()[1]
HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
advantages. These pages can be held for a significant time. But
get_user_pages_fast() does not
In jessie and earlier, this has to be done with a global option.
In later releases, it can be done by putting some options in [ ]
in the relevant sources list entry.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 13 +
1 file changed, 13 insertions(+)
diff --git
Some time on 2019-02-07, Debian removed linux-base from
jessie-backports. This caused everything to break: apt wasn't happy
to get linux-base from jessie-security (because of our -t
jessie-backports, probably) and that meant there was no linux-base
suitable for linux-image-4.9.x on arm64. We
If this is set, use it instead of the usual DebianMirrorHost and
Subpath. No functional change with configs that don't set it.
This is not sufficient to work right yet, because snapshots
repositories have out-of-date signatures...
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 5 -
1
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index ee7e03cf..5e74e86e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -949,6 +949,8 @@ sub
On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
wrote:
>
> On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote:
> > > >>> On 13.02.19 at 17:00, wrote:
> > > > On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
> >
Ian Jackson writes ("[OSSTEST PATCH 0/4] Use snapshot for jessie-backports"):
> Things are being removed from jessie-backports, which we rely on for
> arm64 tests. Switch to using snapshot.debian.org.
>
> In my moderately-formal test, this has got as far as booting one of
> the machines into
On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> Greetings,
>
> On the 11/14/18 Xen x86 community call a discussion was initiated about
> using Kconfig to build minimized versions of Xen for security, safety
> and other certification requirements. After some offline discussions
flight 133233 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133233/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
On Wed, 13 Feb 2019, Rich Persaud wrote:
> On Feb 4, 2019, at 13:22, Stefano Stabellini wrote:
>
> On Mon, 4 Feb 2019, Roger Pau Monné wrote:
> Yes, v7 was sent to address Jan and Julien's review
> comments in parallel
>
> with our ongoing discussion
On Thu, Feb 07, 2019 at 05:58:56AM -0700, Jan Beulich wrote:
> >>> On 06.02.19 at 21:41, wrote:
> > Slightly RFC:
> >
> > 1) I've not worked out exactly what the
> >
> > v->vcpu_info = (void *)>shared_info->compat.vcpu_info[0];
> >
> >line is supposed to be doing and whether it is
On Wed, 13 Feb 2019, Wei Liu wrote:
> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> > Greetings,
> >
> > On the 11/14/18 Xen x86 community call a discussion was initiated about
> > using Kconfig to build minimized versions of Xen for security, safety
> > and other
On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk
wrote:
>
> On Wed, Feb 13, 2019 at 01:38:21PM -0500, Michael Labriola wrote:
> > On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
> > wrote:
> > >
> > > On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk
> > > wrote:
> > > >
> > > > On
On 13/02/2019 20:15, Michael Labriola wrote:
> On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk
> wrote:
>> On Wed, Feb 13, 2019 at 01:38:21PM -0500, Michael Labriola wrote:
>>> On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
>>> wrote:
On Wed, Feb 13, 2019 at 11:57 AM Konrad
On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk
wrote:
>
> On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote:
> > >>> On 13.02.19 at 17:00, wrote:
> > > On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
> > >> >>> On 13.02.19 at 15:10, wrote:
> > >> > Ah, so this isn't
Things are being removed from jessie-backports, which we rely on for
arm64 tests. Switch to using snapshot.debian.org.
In my moderately-formal test, this has got as far as booting one of
the machines into Xen. It's currently doing the guest install, which
I expect to be fine.
Impact on the
On Wed, Feb 13, 2019 at 3:21 PM Andrew Cooper wrote:
>
> On 13/02/2019 20:15, Michael Labriola wrote:
> > On Wed, Feb 13, 2019 at 2:16 PM Konrad Rzeszutek Wilk
> > wrote:
> >> On Wed, Feb 13, 2019 at 01:38:21PM -0500, Michael Labriola wrote:
> >>> On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
On Wed, Feb 13, 2019 at 01:38:21PM -0500, Michael Labriola wrote:
> On Wed, Feb 13, 2019 at 1:16 PM Michael Labriola
> wrote:
> >
> > On Wed, Feb 13, 2019 at 11:57 AM Konrad Rzeszutek Wilk
> > wrote:
> > >
> > > On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote:
> > > > >>> On 13.02.19
flight 133244 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133244/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
flight 133201 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133201/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
On Wed, Feb 13, 2019 at 09:09:32AM -0700, Jan Beulich wrote:
> >>> On 13.02.19 at 17:00, wrote:
> > On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
> >> >>> On 13.02.19 at 15:10, wrote:
> >> > Ah, so this isn't necessarily Xen-specific but rather any paravirtual
> >> > guest? That hadn't
On Wed, Feb 13, 2019 at 09:01:07AM -0700, Jan Beulich wrote:
> >>> On 11.02.19 at 18:46, wrote:
> > There have been several reports of the dom0 builder running out of
> > memory when building a PVH dom0 without having specified a dom0_mem
> > value. Print a warning message if dom0_mem is not set
flight 133231 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133231/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions
On Wed, Feb 13, 2019 at 11:09 AM Jan Beulich wrote:
>
> >>> On 13.02.19 at 17:00, wrote:
> > On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
> >> >>> On 13.02.19 at 15:10, wrote:
> >> > Ah, so this isn't necessarily Xen-specific but rather any paravirtual
> >> > guest? That hadn't crossed
On 2/13/19 3:45 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Woods, Brian [mailto:brian.wo...@amd.com]
>> Sent: 12 February 2019 20:14
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Suthikulpanit, Suravee ; Jan Beulich
>> ; Andrew Cooper ; Wei Liu
>> ; Roger Pau
>>> On 11.02.19 at 18:46, wrote:
> So that the iommu is initialized before populating the p2m, and
> entries added get the corresponding iommu page table entries if
> required. This requires splitting the current pvh_setup_p2m into two
> different functions. One that crafts dom0 physmap and sets
>>> On 13.02.19 at 14:25, wrote:
> @@ -592,6 +592,19 @@ int vm_event_domctl(struct domain *d, struct
> xen_domctl_vm_event_op *vec,
> {
> int rc;
>
> +if ( vec->op == XEN_VM_EVENT_GET_INTERFACE_VERSION )
> +{
> +vec->u.get_interface_version.value =
>>> On 11.02.19 at 18:46, wrote:
> The p2m and iommu mapping code always had the requirement that
> addresses and orders must be aligned when populating the p2m or the
> iommu page tables.
>
> PVH dom0 builder didn't take this requirement into account, and can
> call into the p2m/iommu mapping
>>> On 11.02.19 at 18:46, wrote:
> The assert was originally added to make sure that higher order
> regions (> PAGE_ORDER_4K) could not be used to bypass the
> mmio_ro_ranges check performed by p2m_type_to_flags.
>
> This however is already checked in set_mmio_p2m_entry, which makes
> sure that
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Woods, Brian
> Sent: 13 February 2019 15:34
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu
> ; Jan Beulich ; Suthikulpanit,
> Suravee ; Roger Pau Monne
>
On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
>
> >>> On 13.02.19 at 15:10, wrote:
> > On Wed, Feb 13, 2019 at 5:34 AM Jan Beulich wrote:
> >>
> >> >>> On 12.02.19 at 19:46, wrote:
> >> > Konrad,
> >> >
> >> > Starting w/ v4.17, I cannot log in to GNOME w/out getting the
> >> > following
>>> On 11.02.19 at 18:46, wrote:
> There have been several reports of the dom0 builder running out of
> memory when building a PVH dom0 without having specified a dom0_mem
> value. Print a warning message if dom0_mem is not set when booting in
> PVH mode.
>
> This is a temporary workaround until
91 matches
Mail list logo
