Hi Julien,
On 16.03.2021 15:54, Julien Grall wrote:
> Hi Michal,
>
> On 15/03/2021 09:23, Michal Orzel wrote:
>> Currently in order to link existing DTB into Xen image
>> we need to either specify option CONFIG_DTB_FILE on the
>> command line or manually add it into .config.
>> Add Kconfig entry:
On 17.03.21 15:32, Luca Fancellu wrote:
Hi all,
we've been encountering an issue when using the kernel 5.10 with
preempt_rt support for Dom0, the problem is that during the boot of
Dom0, it hits a BUG_ON(!irqs_disabled()) from the
function evtchn_fifo_unmask defined in events_fifo.c.
This
Hi Juergen,
If you are willing to do the patch I think it will be faster to being accepted,
what about the BUG_ON(…) in evtchn_2l_unmask from events_2l.c file?
Cheers,
Luca
> On 18 Mar 2021, at 07:54, Jürgen Groß wrote:
>
> On 17.03.21 15:32, Luca Fancellu wrote:
>> Hi all,
>> we've been enc
flight 160122 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160122/
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-armhf-libvirt
On 17.03.2021 16:55, Ian Jackson wrote:
> Jan Beulich writes ("Re: libxl / xen-pciback interaction [and 1 more
> messages]"):
>> On 17.03.2021 16:12, Ian Jackson wrote:
>>> How does what libxl is doing differ from a setup, immediately followed
>>> by a hot-add ?
>>
>> In the hot-add case libxl dri
On 18.03.2021 08:21, Michal Orzel wrote:
> Hi Julien,
>
> On 16.03.2021 15:54, Julien Grall wrote:
>> Hi Michal,
>>
>> On 15/03/2021 09:23, Michal Orzel wrote:
>>> Currently in order to link existing DTB into Xen image
>>> we need to either specify option CONFIG_DTB_FILE on the
>>> command line or
On 17.03.2021 14:37, Ian Jackson wrote:
> I have read this thread and with my release manager hat on I feel
> confused and/or ignorant.
>
> Patch 3/ has a good explanation of what the problem is it is
> addressing and why this is important for 4.15. But then there is
> Jan's most recent reply sta
On 17.03.2021 15:46, Ian Jackson wrote:
> Jan, what is your summary opinion about patch 3 ?
Just to answer this question explicitly: I can't form one yet
without further information provided to me.
Jan
None of these are regressions afaict, so considering how late we are
in the 4.15 process, I can see reasons to not take any of these. All
of them are backporting candidates though, imo.
1: correct off-by-1 in number-of-IOMMUs check
2: leave FECTL write to vtd_resume()
3: re-order register restorin
Otherwise, if we really run on a system with this many IOMMUs,
entering/leaving S3 would overrun iommu_state[].
Signed-off-by: Jan Beulich
---
There are more anomalies here, but since we were asked to not make any
cosmetic changes for patches to have a chance to go into 4.15, I've put
off correct
We shouldn't blindly unmask the interrupt when resuming. vtd_resume()
will restore the intended state.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2092,7 +2092,7 @@ static int adjust_vtd_irq_affinities(voi
}
__initcall(adju
For one FECTL must be written last - the interrupt shouldn't be unmasked
without first having written the data and address needed to actually
deliver it. In the common case (when dma_msi_set_affinity() doesn't end
up bailing early) this happens from init_vtd_hw(), but for this to
actually have the
On 18/03/2021 07:21, Michal Orzel wrote:
Hi Julien,
On 16.03.2021 15:54, Julien Grall wrote:
Hi Michal,
On 15/03/2021 09:23, Michal Orzel wrote:
Currently in order to link existing DTB into Xen image
we need to either specify option CONFIG_DTB_FILE on the
command line or manually add it in
Leaving the hooks untouched is at best a latent risk: There may well be
cases where some flush is needed, which then needs carrying out the
"register" way.
Switch from u to uint_t while needing to touch the function
headers anyway.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/ex
On 17/03/2021 17:04, Luca Fancellu wrote:
Hi,
Hi Luca,
I’ve checked the common code and the arm part, I can confirm that the domid 0
is never allocated even if the domain 0 is not present, here the only places
where domain_create(…) is called using a variable value:
Thanks for checking
On 18.03.2021 10:20, Jan Beulich wrote:
> On 18.03.2021 08:21, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 16.03.2021 15:54, Julien Grall wrote:
>>> Hi Michal,
>>>
>>> On 15/03/2021 09:23, Michal Orzel wrote:
Currently in order to link existing DTB into Xen image
we need to either speci
Hi Julien,
I will create a new serie with all the improvements we have discussed.
Thank you for your time.
Cheers,
Luca
> On 18 Mar 2021, at 11:13, Julien Grall wrote:
>
>
>
> On 17/03/2021 17:04, Luca Fancellu wrote:
>> Hi,
>
> Hi Luca,
>
>> I’ve checked the common code and the arm part
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-368
version 2
HVM soft-reset crashes toolstack
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
libxl req
flight 160119 qemu-mainline real [real]
flight 160124 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160119/
http://logs.test-lab.xenproject.org/osstest/logs/160124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28687 / XSA-368
version 3
HVM soft-reset crashes toolstack
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
li
flight 160123 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160123/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9fd7e88c23f6fb056d25fbc3f8e2e7c1a53859d1
baseline version:
ovmf 030ba3097a6e7d08b99f8
On 3/16/21 12:09 AM, Daniel P. Smith wrote:
> All,
>
> We have posted[1][2] the design documents for hyperlaunch and would
> invite attendance at a working group call to discuss two agenda items.
> The first item is a review of the documents and the second is a
> discussion about bringing producti
Hi Konrad,
this series contains a bunch of swiotlb cleanups, mostly to reduce the
amount of internals exposed to code outside of swiotlb.c, which should
helper to prepare for supporting multiple different bounce buffer pools.
Changes since v2:
- fix a bisetion hazard that did not allocate the al
flight 160120 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160120/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 160109 pass in 160120
test-amd64-amd64-xl-qemut-debian
From: Claire Chang
Added a new struct, io_tlb_mem, as the IO TLB memory pool descriptor and
moved relevant global variables into that struct.
This will be useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
[hch: rebased]
Signed-off-by: Christoph Hellwig
---
drivers/xen
Instead of allocating ->list and ->orig_addr separately just do one
dynamic allocation for the actual io_tlb_mem structure. This simplifies
a lot of the initialization code, and also allows to just check
io_tlb_default_mem to see if swiotlb is in use.
Signed-off-by: Christoph Hellwig
---
driver
flight 160126 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160126/
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
All callers just use it to check if swiotlb is active at all, for which
they can just use is_swiotlb_active. In the longer run drivers need
to stop using is_swiotlb_active as well, but let's do the simple step
first.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_interna
Just took a quick look at it.
On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote:
> +
> +---+---++---+-+-+
> + | **Xen Dom0** | **Linux** | **Late** | **Jail** | **Xen** | **Xen
> Hyperlaunch** |
> + | *
[Adding George, since it's scheduling]
On Mon, 2021-03-15 at 12:18 +, Ian Jackson wrote:
>
> OPEN ISSUES AND BLOCKERS
>
>
> [...]
>
> SCHEDULER ISSUES NOT MAKING PROCESS ?
> -
>
Yeah... let's try.
> BUG: credit=sched2 machine ha
flight 160121 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs.
152332
test-amd64-i3
When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some
toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum
addressable physical memory in the VM and for forks that have not yet been
unpaused that value is not going to reflect the correct max gpfn that
On Wed, 17 Mar 2021, Boris Ostrovsky wrote:
> On 2/25/21 6:51 PM, Stefano Stabellini wrote:
> > Newer Xen versions expose two Xen feature flags to tell us if the domain
> > is directly mapped or not. Only when a domain is directly mapped it
> > makes sense to enable swiotlb-xen on ARM.
> >
> > Intr
flight 160125 qemu-mainline real [real]
flight 160133 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160125/
http://logs.test-lab.xenproject.org/osstest/logs/160133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 160127 xen-4.14-testing real [real]
flight 160136 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160127/
http://logs.test-lab.xenproject.org/osstest/logs/160136/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
35 matches
Mail list logo
