flight 164095 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164095/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164089
test-armhf-armhf-libvirt 16 sav
Set/Way flushes never work correctly in a virtualized environment.
Our current implementation is based on clearing the valid bit in the p2m
pagetable to track guest memory accesses. This technique doesn't work
when the IOMMU is enabled for the domain and the pagetable is shared
between IOMMU and M
On Tue, 3 Aug 2021, Julien Grall wrote:
> Hi,
>
> Title: How about:
>
> "xen/arm: Do not invalidate the P2M when the PT is shared with the IOMMU"
OK
> On 03/08/2021 22:37, Stefano Stabellini wrote:
> > Set/Way flushes never work correctly in a virtualized environment.
> >
> > Our current impl
flight 164094 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164094/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164086
test-armhf-armhf-libvirt 16 save
Hi,
Title: How about:
"xen/arm: Do not invalidate the P2M when the PT is shared with the IOMMU"
On 03/08/2021 22:37, Stefano Stabellini wrote:
Set/Way flushes never work correctly in a virtualized environment.
Our current implementation is based on clearing the valid bit in the p2m
pagetable
Set/Way flushes never work correctly in a virtualized environment.
Our current implementation is based on clearing the valid bit in the p2m
pagetable to track guest memory accesses. This technique doesn't work
when the IOMMU is enabled for the domain and the pagetable is shared
between IOMMU and M
flight 164091 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 164093 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164093/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 55266a9b8ac71dace1109d61be549889cdd2f93f
baseline version:
ovmf 2b47aaecef38b9440a658
On Tue, 2021-08-03 at 19:36 +0200, Dario Faggioli wrote:
> It should, therefore, be backported and applied to all the branches
> to
> which that commit has been. About backports, it should be
> straigthforward to do that until 4.13.
>
> For 4.12 and earlier, it's trickier, but the fix is still nec
Err... of course, the "pli" and "bla" stuff between the [] are a
leftover of some experiments that I had to do with `stg email`, due to
mail handling changes, and should really not have been there in this
email...
Sorry. :-/
On Tue, 2021-08-03 at 19:36 +0200, Dario Faggioli wrote:
> Commit 07b0eb
Commit 07b0eb5d0ef0 ("credit2: make sure we pick a runnable unit from the
runq if there is one") did not fix completely the problem of potentially
selecting a scheduling unit that will then not be able to run.
In fact, in case caps are used and the unit we are currently looking
at, during the runq
flight 164089 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164089/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 164084
Tests which did not succee
On Tue, Aug 03, 2021 at 12:01:49PM +0200, Uwe Kleine-König wrote:
> This prepares removing the driver member of struct pci_dev which holds the
> same information than struct pci_dev::dev->driver.
...
> + struct pci_driver *pdrv;
Missed blank line here and everywhere else. I don't remember if
On Tue, Aug 03, 2021 at 12:01:48PM +0200, Uwe Kleine-König wrote:
> Which driver a device is bound to is available twice: In struct
> pci_dev::dev->driver and in struct pci_dev::driver. To get rid of the
> duplication introduce a wrapper to access struct pci_dev's driver
> member. Once all users ar
flight 164092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164092/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 8/3/21 6:01 AM, Uwe Kleine-König wrote:
> This prepares removing the driver member of struct pci_dev which holds the
> same information than struct pci_dev::dev->driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
> arch/powerpc/include/asm/ppc-pci.h| 3 +-
> arch/powerpc/kernel/e
On Tue, Aug 03, 2021 at 03:44:10PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:30, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
> >> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
> >>> On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beul
flight 164090 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164090/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2b47aaecef38b9440a65809cbdaf9d97029f4eeb
baseline version:
ovmf 03e77558d4939b9c21e94
On 8/3/21 6:01 AM, Uwe Kleine-König wrote:
> pcifront_common_process() has a check at the start that exits early if
> pcidev or pdidev->driver are NULL. So simplify the following code by not
> checking these two again.
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/pci/xen-pcifront.c | 57
On 03.08.2021 15:30, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
>> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
>>> On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote
On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
> > On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
> >> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
> >>> Ok, then, just setting iommu_intremap=false should
On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
>> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
>>> Ok, then, just setting iommu_intremap=false should do the right thing,
>>
>> ... if "iommu=force" is in use (but not ot
On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
> > Ok, then, just setting iommu_intremap=false should do the right thing,
>
> ... if "iommu=force" is in use (but not otherwise), ...
But that's the purpose of iommu=force, no?
W
On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 03, 2021 at 02:29:01PM +0200, Jan Beulich wrote:
>> On 03.08.2021 14:21, Marek Marczykowski-Górecki wrote:
>>> If we would have an option (in
>>> toolstack, or Xen) to force interrupt remapping, then indeed when it's
>>> broken, P
On Tue, Aug 03, 2021 at 02:29:01PM +0200, Jan Beulich wrote:
> On 03.08.2021 14:21, Marek Marczykowski-Górecki wrote:
> > If we would have an option (in
> > toolstack, or Xen) to force interrupt remapping, then indeed when it's
> > broken, PCI passthrough should be refused (or maybe even system sho
On 30.07.2021 18:13, Oleksandr wrote:
> Well, if new hypercall and, what is more, "the querying hypervisor at
> runtime to find unused space" model itself is not welcome, I am ok,
> let's try to create a working system,
> may we please find a common ground to move this forward (at least on Arm
>
Hi Jan,
On 03/08/2021 13:49, Jan Beulich wrote:
On 28.07.2021 21:53, Julien Grall wrote:
On 28/07/2021 20:00, Andrew Cooper wrote:
On 28/07/2021 18:27, Julien Grall wrote:
On 28/07/2021 18:19, Andrew Cooper wrote:
On 28/07/2021 17:18, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
On 28.07.2021 21:53, Julien Grall wrote:
> On 28/07/2021 20:00, Andrew Cooper wrote:
>> On 28/07/2021 18:27, Julien Grall wrote:
>>> On 28/07/2021 18:19, Andrew Cooper wrote:
On 28/07/2021 17:18, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Add XENMEM_get_unallocat
On 03.08.2021 14:21, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 03, 2021 at 01:13:40PM +0200, Jan Beulich wrote:
>> While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
>> spec update, X58's also mentions B2, and searching the internet suggests
>> systems with this stepping are
On Tue, Aug 03, 2021 at 01:13:40PM +0200, Jan Beulich wrote:
> While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
> spec update, X58's also mentions B2, and searching the internet suggests
> systems with this stepping are actually in use. Even worse, for X58
> erratum #69 is marke
While for 5500 and 5520 chipsets only B3 and C2 are mentioned in the
spec update, X58's also mentions B2, and searching the internet suggests
systems with this stepping are actually in use. Even worse, for X58
erratum #69 is marked applicable even to C2. Split the check to cover
all applicable step
On 30.07.2021 11:00, Juergen Gross wrote:
> On 16.06.21 12:43, Juergen Gross wrote:
>> On 16.06.21 11:56, Jan Beulich wrote:
>>> On 16.06.2021 09:30, Juergen Gross wrote:
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -95,8 +95,8 @@ unsigned long *xen_p2m_addr __read_mostly;
>>
flight 164086 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164086/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164077
test-armhf-armhf-libvirt 16 save
Currently it's tracked twice which driver is bound to a given pci
device. Now that all users of the pci specific one (struct
pci_dev::driver) are updated to use an access macro
(pci_driver_of_dev()), change the macro to use the information from the
driver core and remove the driver member from stru
This prepares removing the driver member of struct pci_dev which holds the
same information than struct pci_dev::dev->driver.
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/include/asm/ppc-pci.h| 3 +-
arch/powerpc/kernel/eeh_driver.c | 12 ---
arch/x86/events/int
Hello,
changes since v1
(https://lore.kernel.org/linux-pci/20210729203740.1377045-1-u.kleine-koe...@pengutronix.de):
- New patch to simplify drivers/pci/xen-pcifront.c, spotted and
suggested by Boris Ostrovsky
- Fix a possible NULL pointer dereference I introduced in xen-pcifront.c
- A few whi
Which driver a device is bound to is available twice: In struct
pci_dev::dev->driver and in struct pci_dev::driver. To get rid of the
duplication introduce a wrapper to access struct pci_dev's driver
member. Once all users are converted the wrapper can be changed to
calculate the driver using pci_d
pcifront_common_process() has a check at the start that exits early if
pcidev or pdidev->driver are NULL. So simplify the following code by not
checking these two again.
Signed-off-by: Uwe Kleine-König
---
drivers/pci/xen-pcifront.c | 57 +-
1 file changed, 25
Hi Julien,
> On 19 Jul 2021, at 09:58, Julien Grall wrote:
>
>
>
> On 16/07/2021 18:14, Bertrand Marquis wrote:
>> Hi Julien
>
> Hi Bertrand,
>
>> […]
+
+if ( old_reg != new_reg )
+printk(XENLOG_DEBUG "SANITY DIF: %s 0x%"PRIx64" -> 0x%"PRIx64"\n",
+
On 03/08/2021 01:23, Stefano Stabellini wrote:
Hi all,
Hi Stefano,
This series introduces support for the generic SMMU bindings to
xen/drivers/passthrough/arm/smmu.c.
Committed.
Cheers,
--
Julien Grall
Hi Stefano,
On 03/08/2021 01:24, Stefano Stabellini wrote:
iommu_add_dt_device() returns -EEXIST if the device was already
registered. At the moment, this can only happen if the device was
already assigned to a domain (either dom0 at boot or via
XEN_DOMCTL_assign_device).
In a follow-up patch,
Hi Stefano,
On 03/08/2021 01:24, Stefano Stabellini wrote:
From: Brian Woods
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, making enabling generic device tree
bindings in the SMMU dr
Hi Jan,
On 03/08/2021 07:57, Jan Beulich wrote:
On 26.07.2021 17:45, Julien Grall wrote:
On 23/07/2021 14:02, Jan Beulich wrote:
On 23.07.2021 11:28, Julien Grall wrote:
On 23/07/2021 07:31, Jan Beulich wrote:
On 23.07.2021 01:36, Stefano Stabellini wrote:
--- a/xen/drivers/passthrough/devi
On 24.07.2021 22:07, Daniel P. Smith wrote:
> On 7/16/21 3:34 AM, Jan Beulich wrote:
>> On 12.07.2021 22:32, Daniel P. Smith wrote:
>>> With the elimination of switching how dummy.h gets included, the function
>>> declaration macros are no longer necessary. This commit expands them out to
>>> the
Hello guys,
During the last Xen community call I was talking about my work to port XTF to
arm(more specifically arm64).
There was quite a bigh interest in this topic hence I created a pull request
for Andrew's XTF on github with the first patch series.
It consists of several patches creating a b
flight 164088 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164088/
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 25.07.2021 22:47, Daniel P. Smith wrote:
> On 7/19/21 6:24 AM, Jan Beulich wrote:
>> On 12.07.2021 22:32, Daniel P. Smith wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -200,23 +200,20 @@ config XENOPROF
>>>
>>> If unsure, say Y.
>>>
>>> -config XSM
>>> - boo
On 02.08.21 22:26, Julien Grall wrote:
> Hi,
>
> On 02/08/2021 15:06, Oleksandr Andrushchenko wrote:
>> On 30.07.21 13:38, Juergen Gross wrote:
>>> In order to avoid problems in case the backend is modifying a response
>>> on the ring page while the frontend has already seen it, just read the
>>>
48 matches
Mail list logo
