On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch
> > here.
> >
> >
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
>
> is_swiotlb_force_bounce() was the new function introduced in this patch here.
>
> +static inline bool is_swiotlb_force_bounce(struct device *dev)
> +{
> +
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:30 PM
>
> Replace uses of QINVAL_ENTRY_ORDER and QINVAL_INDEX_SHIFT, such that
> the constants can be dropped. Move the remaining QINVAL_* ones to the
> single source file using them.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:30 PM
>
> Introduce a helper function to reduce redundancy. Take the opportunity
> to express the logic without using the somewhat odd QINVAL_ENTRY_ORDER.
> Also take the opportunity to uniformly unmap after updating queue tail
> and dropping
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:29 PM
>
> While no longer an immediate problem with flushes no longer timing out,
> errors (if any) get properly reported by iommu_flush_iotlb_{dsi,psi}().
> Overwriting such an error with, perhaps, a success indicator received
> from another I
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:29 PM
>
> If there is any way for one fault to be left set in the recording
> registers, there's no reason there couldn't also be multiple ones. If
> PPF set set (being the OR or all F fields), simply loop over the entire
> range of fault reco
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:28 PM
>
> When an earlier error occurred, cleaning up the domid mapping data is
> wrong, as references likely still exist. The only exception to this is
> when the actual unmapping worked, but some flush failed (supposedly
> impossible after X
> From: Jan Beulich
> Sent: Wednesday, June 9, 2021 5:28 PM
>
> When
> - flushes (supposedly not possible anymore after XSA-373),
> - secondary mappings for legacy PCI devices behind bridges,
> - secondary mappings for chipset quirks, or
> - find_upstream_bridge() invocations
> fail, the succ
re_class
[ 22.362512][ T256] igb 0006:01:00.0: eth0: PBA No: G69016-004
[ 22.372287][T7] CPU: 13 PID: 7 Comm: kworker/u64:0 Not tainted
5.13.0-rc7-next-20210623+ #47
[ 22.372293][T7] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR,
BIOS 1.6 06/28/2020
[ 22.372298][T7] Workq
On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, Claire Chang wrote:
>>> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
>>> use it to determine whether to bounce the data or not. This will
flight 163003 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 162998 linux-5.4 real [real]
flight 163008 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162998/
http://logs.test-lab.xenproject.org/osstest/logs/163008/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
On Mon, 10 May 2021, Luca Fancellu wrote:
> Modification to include/public/grant_table.h:
>
> 1) Add doxygen tags to:
> - Create Grant tables section
> - include variables in the generated documentation
> - Used @keepindent/@endkeepindent to enclose comment
>section that are indented using
On Mon, 10 May 2021, Luca Fancellu wrote:
> Create a skeleton for the documentation about hypercalls
>
> Signed-off-by: Luca Fancellu
> ---
> v6 changes:
> - Now every platform has the same sections in .rst files
> ---
> .gitignore | 1 +
> docs/Makefile
On Mon, 10 May 2021, Luca Fancellu wrote:
> Modify docs/Makefile to call doxygen and generate sphinx
> html documentation given the doxygen XML output.
>
> Modify docs/conf.py sphinx configuration file to setup
> the breathe extension that works as bridge between
> sphinx and doxygen.
>
> Add som
flight 162999 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162999/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On 6/23/21 9:09 AM, Juergen Gross wrote:
> In order to avoid a race condition for user events when changing
> cpu affinity reset the active flag only when EOI-ing the event.
>
> This is working fine as all user events are lateeoi events. Note that
> lateeoi_ack_mask_dynirq() is not modified as th
On Mon, 10 May 2021, Luca Fancellu wrote:
> Add preprocessor called by doxygen before parsing headers,
> it will include in every header a doxygen_include.h file
> that provides missing defines and includes that are
> usually passed by the compiler.
>
> Add doxy_input.list that is a text file cont
flight 162996 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
On Wed, 23 Jun 2021, Rahul Singh wrote:
> Hi Stefano,
>
> > On 23 Jun 2021, at 9:09 am, Rahul Singh wrote:
> >
> > Hi Stefano,
> >
> >> On 22 Jun 2021, at 10:06 pm, Stefano Stabellini
> >> wrote:
> >>
> >> Hi Rahul,
> >>
> >> Do you have an opinion on how we should move forward on this?
> >>
>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid guest-saverestore
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://xen
Hi Robin,
On Mon, Jun 14, 2021 at 02:29:08PM +0100, Robin Murphy wrote:
> On 2021-06-13 07:29, Salvatore Bonaccorso wrote:
> > A user in Debian reported the above issue, which was reproducible with
> > 5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
> > ("swiotlb: don't modif
On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>
>
> On 6/18/2021 11:40 PM, Claire Chang wrote:
> > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> > use it to determine whether to bounce the data or not. This will be
> > useful later to allow for different pool
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
testid guest-saverestore
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 gi
flight 162971 xen-unstable real [real]
flight 163000 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162971/
http://logs.test-lab.xenproject.org/osstest/logs/163000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Hi Stefano,
> On 23 Jun 2021, at 9:09 am, Rahul Singh wrote:
>
> Hi Stefano,
>
>> On 22 Jun 2021, at 10:06 pm, Stefano Stabellini
>> wrote:
>>
>> Hi Rahul,
>>
>> Do you have an opinion on how we should move forward on this?
>>
>> Do you think it is OK to go for a full revert of "xen/arm: smmuv1
flight 162986 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 162995 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
In order to avoid a race condition for user events when changing
cpu affinity reset the active flag only when EOI-ing the event.
This is working fine as all user events are lateeoi events. Note that
lateeoi_ack_mask_dynirq() is not modified as there is no explicit call
to xen_irq_lateeoi() expecte
flight 162969 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-am
Hi Juergen,
On 22/06/2021 17:14, Juergen Gross wrote:
On 22.06.21 14:21, Julien Grall wrote:
Hi Juergen,
On 22/06/2021 13:04, Juergen Gross wrote:
On 22.06.21 12:24, Julien Grall wrote:
Hi Juergen,
As discussed on IRC yesterday, we noticed a couple of splat in 5.13-rc6
(and stable 5.4)
flight 162994 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162994/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 162987 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
flight 162992 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162992/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen c7691f5e340f3b579d40c77548f63133cdf5aac7
baseline version:
xen 4bcf
Hello everyone!
Please welcome Ashley Weltz, our new Project Coordinator from the Linux
Foundation. As the job title implies, Ashley will be helping out with various
project coordination activities, including chairing the monthly community call
and running the jobs page. So don’t be surprised
On Wed, Jun 23, 2021 at 4:38 PM Konrad Rzeszutek Wilk
wrote:
>
> On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory at une
Thanks Boris, I will fix this in V8
On 6/23/2021 1:31 AM, Boris Ostrovsky wrote:
On 6/22/21 5:38 AM, Zhu Lingshan wrote:
-static int xen_is_user_mode(void)
-{
- const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
+ state |= PERF_GUEST_ACTIVE;
- if (!xenpmu_data) {
-
On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data le
Hi Stefano,
> On 22 Jun 2021, at 10:06 pm, Stefano Stabellini
> wrote:
>
> Hi Rahul,
>
> Do you have an opinion on how we should move forward on this?
>
> Do you think it is OK to go for a full revert of "xen/arm: smmuv1:
> Intelligent SMR allocation" or do you think it is best to go with an
39 matches
Mail list logo
