On 14.02.2021 15:35, Julien Grall wrote:
> From: Julien Grall
>
> ... are the same.
>
> When the IOMMU is enabled and the domain is direct mapped (e.g. Dom0),
> Xen will insert a 1:1 mapping for each grant mapping in the P2M to
> allow DMA.
>
> This works quite well when the grantee and granter
On 15.02.21 08:37, Anders Törnqvist wrote:
Hi,
I would like to shorten the boot time in our system if possible.
In xen/common/warning.c there is warning_print() which contains a 3
seconds loop that calls process_pending_softirqs().
What would the potential problems be if that loop is radica
On 13.02.2021 14:50, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 12, 2021 at 06:05:40PM -0800, Stefano Stabellini wrote:
>> If rombios, seabios and ovmf are all disabled, don't attempt to build
>> hvmloader.
>
> What if you choose to not build any of rombios, seabios, ovmf, but use
> system on
flight 159366 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159366/
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
On 15.02.2021 09:13, Jürgen Groß wrote:
> On 15.02.21 08:37, Anders Törnqvist wrote:
>> I would like to shorten the boot time in our system if possible.
>>
>> In xen/common/warning.c there is warning_print() which contains a 3
>> seconds loop that calls process_pending_softirqs().
>>
>> What woul
On 15.02.21 09:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
On 15.02.21 08:37, Anders Törnqvist wrote:
I would like to shorten the boot time in our system if possible.
In xen/common/warning.c there is warning_print() which contains a 3
seconds loop that calls process_pending
On Sun, Feb 14, 2021 at 07:27:46PM -0800, Elliott Mitchell wrote:
> On Sun, Feb 14, 2021 at 11:45:47PM +0100, Maximilian Engelhardt wrote:
> > On Samstag, 13. Februar 2021 19:21:56 CET Elliott Mitchell wrote:
> > > On Sat, Feb 13, 2021 at 04:36:24PM +0100, Maximilian Engelhardt wrote:
> > > > * The
Hello Julien,
> On 14 Feb 2021, at 2:32 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 11/02/2021 16:05, Rahul Singh wrote:
>>> On 11 Feb 2021, at 1:52 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 11/02/2021 13:20, Rahul Singh wrote:
Hello Julien,
>>>
>>> Hi Rahul,
>>>
> On 10 Feb 20
flight 159359 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 158387
test-arm64-arm64-xl-x
Hi Juergen,
On 15/02/2021 08:51, Jürgen Groß wrote:
On 15.02.21 09:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
On 15.02.21 08:37, Anders Törnqvist wrote:
I would like to shorten the boot time in our system if possible.
In xen/common/warning.c there is warning_print() which
Hi Jan,
On 15/02/2021 08:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
On 15.02.21 08:37, Anders Törnqvist wrote:
I would like to shorten the boot time in our system if possible.
In xen/common/warning.c there is warning_print() which contains a 3
seconds loop that calls proc
On 15.02.2021 11:35, Julien Grall wrote:
> On 15/02/2021 08:38, Jan Beulich wrote:
>> On 15.02.2021 09:13, Jürgen Groß wrote:
>>> On 15.02.21 08:37, Anders Törnqvist wrote:
I would like to shorten the boot time in our system if possible.
In xen/common/warning.c there is warning_print
Hi Jan,
On 15/02/2021 10:41, Jan Beulich wrote:
On 15.02.2021 11:35, Julien Grall wrote:
On 15/02/2021 08:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
On 15.02.21 08:37, Anders Törnqvist wrote:
I would like to shorten the boot time in our system if possible.
In xen/common/
Am 18.01.2021 um 16:49 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 18 January 2021 15:34
> > To: qemu-de...@nongnu.org
> > Cc: Roger Pau Monne ; Arthur Borsboom
> > ; Stefano
> > Stabellini ; Anthony Perard
> > ; Paul Durrant
> > ; Kevin Wolf
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-credit2
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tr
Hi Rahul,
On 15/02/2021 09:12, Rahul Singh wrote:
Thanks for the testing. I noticed that my patch doesn't build because
arm_iommu_unmap_page() doesn't have a parameter mfn. Can you confirm whether
you had to replace mfn with _mfn(dfn_x(dfn))?
Yes I have to replace the mfn with _mfn(dfn_x(dfn
Hi Jan,
On 10/02/2021 11:26, Jan Beulich wrote:
On 09.02.2021 16:28, Julien Grall wrote:
From: Julien Grall
Currently, the IOMMU page-tables will be populated early in the domain
creation if the hardware is able to virtualize the local APIC. However,
the IOMMU page tables will not be freed du
On 15.02.2021 11:50, Julien Grall wrote:
> Hi Jan,
>
> On 15/02/2021 10:41, Jan Beulich wrote:
>> On 15.02.2021 11:35, Julien Grall wrote:
>>> On 15/02/2021 08:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
> On 15.02.21 08:37, Anders Törnqvist wrote:
>> I would like t
On 15.02.2021 12:38, Julien Grall wrote:
> On 10/02/2021 11:26, Jan Beulich wrote:
>> On 09.02.2021 16:28, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Currently, the IOMMU page-tables will be populated early in the domain
>>> creation if the hardware is able to virtualize the local APIC. Ho
Hi Jan,
On 15/02/2021 12:36, Jan Beulich wrote:
On 15.02.2021 12:38, Julien Grall wrote:
On 10/02/2021 11:26, Jan Beulich wrote:
On 09.02.2021 16:28, Julien Grall wrote:
From: Julien Grall
Currently, the IOMMU page-tables will be populated early in the domain
creation if the hardware is abl
On 15.02.2021 13:54, Julien Grall wrote:
> On 15/02/2021 12:36, Jan Beulich wrote:
>> On 15.02.2021 12:38, Julien Grall wrote:
>>> Given this series needs to go in 4.15 (we would introduce a 0-day
>>> otherwise), could you clarify whether your patch [1] is intended to
>>> replace this one in 4.15?
Hi Jan,
On 15/02/2021 12:29, Jan Beulich wrote:
On 15.02.2021 11:50, Julien Grall wrote:
On 15/02/2021 10:41, Jan Beulich wrote:
On 15.02.2021 11:35, Julien Grall wrote:
On 15/02/2021 08:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
On 15.02.21 08:37, Anders Törnqvist wrote
On 13/02/2021 09:36, Jürgen Groß wrote:
> On 12.02.21 18:01, Andrew Cooper wrote:
>> On 12/02/2021 16:08, Jürgen Groß wrote:
>>> On 12.02.21 16:39, Andrew Cooper wrote:
Various version of gcc, when compiling with -Og, complain:
xenstored_control.c: In function ‘lu_read_state’:
>>
On 15/02/2021 10:41, Jan Beulich wrote:
> On 15.02.2021 11:35, Julien Grall wrote:
>> On 15/02/2021 08:38, Jan Beulich wrote:
>>> On 15.02.2021 09:13, Jürgen Groß wrote:
>> What was just an "annoyance" for boot can now completely wreck your
>> guests and system (not many software can tolerate larg
Hi Andrew,
On 15/02/2021 15:00, Andrew Cooper wrote:
On 15/02/2021 10:41, Jan Beulich wrote:
On 15.02.2021 11:35, Julien Grall wrote:
On 15/02/2021 08:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
What was just an "annoyance" for boot can now completely wreck your
guests and
Various version of gcc, when compiling with -Og, complain:
xenstored_control.c: In function ‘lu_read_state’:
xenstored_control.c:540:11: error: ‘state.size’ is used uninitialized in this
function [-Werror=uninitialized]
if (state.size == 0)
~^
xenstored_control.c:543:6:
flight 159362 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159362/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 159335 pass in 159362
test-armhf-armhf-xl-rtds 18 gues
flight 159364 qemu-mainline real [real]
flight 159385 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159364/
http://logs.test-lab.xenproject.org/osstest/logs/159385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 2/11/21 5:16 AM, Juergen Gross wrote:
> @@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
> bool spurious)
> }
>
> info->eoi_time = 0;
> + smp_store_release(&info->is_active, 0);
Can this be done in lateeoi_ack_dynirq()/lateeoi_mask_ack_dynirq(
On 2/11/21 5:16 AM, Juergen Gross wrote:
> Add syfs nodes for each xenbus device showing event statistics (number
> of events and spurious events, number of associated event channels)
> and for setting a spurious event threshold in case a frontend is
> sending too many events without being rogue
flight 159367 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-arndale
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tr
Hello all,
I found a bug in Xen 4.9 involving what I think is an incorrectly backported
patch for XSA-321. I realize that Xen 4.9 no longer receives security support,
but as a Qubes OS 4.0 user, I still rely on Xen 4.8, and this bug affects me
negatively.
I would really appreciate it if anyone co
This commit aims to fix commit a852040fe3ab ("x86/ept: flush cache when
modifying PTEs and sharing page tables"). The aforementioned commit is
for the stable-4.9 branch of Xen and is a backported version of commit
c23274fd0412 ("x86/ept: flush cache when modifying PTEs and sharing page
tables"), wh
flight 159372 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 14 guest-start fail REGR. vs. 158387
test-arm64-arm64-xl-x
35 matches
Mail list logo
