On 26.08.19 18:38, Nadav Amit wrote:
On Aug 26, 2019, at 12:51 AM, Juergen Gross wrote:
On 24.08.19 00:52, Nadav Amit wrote:
__flush_tlb_one_user() currently flushes a single entry, and flushes it
both in the kernel and user page-tables, when PTI is enabled.
Change __flush_tlb_one_user() and
On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>>On 19/08/2019 02:25, Chao Gao wrote:
>>> register an nmi callback. And this callback does busy-loop on threads
>>> which are waiting for loading completion. Control threads
On Tue, Aug 27, 2019 at 12:17:28AM +0300, Pasi Kärkkäinen wrote:
>Hi Chao,
>
>On Fri, Aug 09, 2019 at 04:38:33PM +0800, Chao Gao wrote:
>> Hi everyone,
>>
>> I have a device which only supports secondary bus reset. After being
>> assigned to a VM, it would be placed under host bridge. For devices
flight 140657 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140657/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 140583 REGR. vs. 140282
On Fri, 16 Aug 2019, Christoph Hellwig wrote:
> Hi Xen maintainers and friends,
>
> please take a look at this series that cleans up the parts of swiotlb-xen
> that deal with non-coherent caches.
Hi Christoph,
I just wanted to let you know that your series is on my radar, but I
have been
flight 140660 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140660/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 4438d71949e8a59f2ac2349a450f6965fee6c6e4
baseline version:
freebsd
flight 140653 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140653/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140632 REGR.
vs. 139698
Tests
flight 140650 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 139936
Hi Chao,
On Fri, Aug 09, 2019 at 04:38:33PM +0800, Chao Gao wrote:
> Hi everyone,
>
> I have a device which only supports secondary bus reset. After being
> assigned to a VM, it would be placed under host bridge. For devices
> under host bridge, secondary bus reset is not applicable. Thus, a VM
Hi,
On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
> On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
> > On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
> >> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
> >>> On 9/18/18 5:32 AM, George Dunlap
flight 140645 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 139876
build-amd64-xsm
flight 140648 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
From: Rich Persaud
Date: Friday, 16 August 2019 at 16:49
To: George Dunlap
Cc: Lars Kurth , xen-devel
, "minios-de...@lists.xenproject.org"
, "mirageos-de...@lists.xenproject.org"
, "win-pv-de...@lists.xenproject.org"
, "committ...@xenproject.org"
Subject: Re: [Xen-devel] [RFC] Code of
> On Aug 26, 2019, at 12:51 AM, Juergen Gross wrote:
>
> On 24.08.19 00:52, Nadav Amit wrote:
>> __flush_tlb_one_user() currently flushes a single entry, and flushes it
>> both in the kernel and user page-tables, when PTI is enabled.
>> Change __flush_tlb_one_user() and related interfaces into
flight 140642 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
139910
> Yes, I could do that. But, I would like to discuss (get guidelines about) the
> expected test coverage.
> With this sort of changes, there is an unlimited set of test-cases to be
> created. So, I would like to focus on a few most important.
> I am missing knowledge how these test cases are
No need for a no-op wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 95911ff9c11c..384304a77020 100644
---
These routines are only used by swiotlb-xen, which cannot be modular.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 2 --
arch/x86/xen/mmu_pv.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 9b3a6c0ca681..b7d53415532b 100644
---
x86 currently calls alloc_pages, but using dma-direct works as well
there, with the added benefit of using the CMA pool if available.
The biggest advantage is of course to remove a pointless bit of
architecture specific code.
Signed-off-by: Christoph Hellwig
---
Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64 file, so switch to use the
asm-generic version instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
---
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/include/asm/dma-mapping.h | 22
xen_dma_map_page uses a different and more complicated check for foreign
pages than the other three cache maintainance helpers. Switch it to the
simpler pfn_valid method a well, and document the scheme with a single
improved comment in xen_dma_map_page.
Signed-off-by: Christoph Hellwig
---
Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 62
The only thing left of page-coherent.h is two functions implemented by
the architecture for non-coherent DMA support that are never called for
fully coherent architectures. Just move the prototypes for those to
swiotlb-xen.h instead.
Signed-off-by: Christoph Hellwig
---
Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore
Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
non-coherent devices.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/device.h | 3 -
arch/arm/include/asm/xen/page-coherent.h | 93 --
arch/arm/mm/dma-mapping.c
Hi Xen maintainers and friends,
please take a look at this series that cleans up the parts of swiotlb-xen
that deal with non-coherent caches.
Changes since v1:
- rewrite dma_cache_maint to be much simpler
- improve various comments and commit logs
- remove page-coherent.h entirely
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
---
arch/arm/mm/dma-mapping.c| 3 ++-
arch/arm/xen/mm.c| 4
arch/arm64/mm/dma-mapping.c | 3 ++-
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant. Note that both are always initialized to the same
value in arch_setup_dma_ops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
---
arch/arm/include/asm/dma-mapping.h | 6 --
flight 140638 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
On Mon, Aug 19, 2019 at 12:45:17PM +0100, Julien Grall wrote:
> On 8/16/19 2:00 PM, Christoph Hellwig wrote:
>> +static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
>> + dma_addr_t dev_addr, unsigned long offset, size_t size,
>> + enum dma_data_direction
On Thu, Aug 22, 2019 at 08:51:32AM +0200, Roger Pau Monne wrote:
> The new format specifier is '%pp', and prints a pci_sbdf_t using the
> seg:bus:dev.func format. Replace all SBDFs printed using
> '%04x:%02x:%02x.%u' to use the new format specifier.
>
> No functional change intended.
>
>
On 13.08.19 19:11, Dario Faggioli wrote:
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
Today a cpu which is removed from the system is taken directly from
Pool0 to the offline state. This will conflict with the new idle
scheduler, so remove it from Pool0 first. Additionally accept
On 13.08.19 18:07, Dario Faggioli wrote:
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
With core or socket scheduling we need to know the number of siblings
per scheduling unit before we can setup the scheduler properly. In
order to prepare that do cpupool0 population only after all
On 13.08.19 17:51, Dario Faggioli wrote:
On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
These three patches have been carved out from my core scheduling
series
as they are sufficiently independent to be applied even without the
big
series.
Without this little series there are messages
On Mon, Aug 26, 2019 at 03:03:22PM +0800, Chao Gao wrote:
> On Fri, Aug 23, 2019 at 10:11:21AM +0200, Roger Pau Monné wrote:
> >On Mon, Aug 19, 2019 at 09:25:25AM +0800, Chao Gao wrote:
> >> To create a microcode patch from a vendor-specific update,
> >> allocate_microcode_patch() copied
flight 140635 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 140583 REGR. vs. 140282
On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>On 19/08/2019 02:25, Chao Gao wrote:
>> register an nmi callback. And this callback does busy-loop on threads
>> which are waiting for loading completion. Control threads send NMI to
>> slave threads to prevent NMI acceptance during
On 24.08.19 00:52, Nadav Amit wrote:
__flush_tlb_one_user() currently flushes a single entry, and flushes it
both in the kernel and user page-tables, when PTI is enabled.
Change __flush_tlb_one_user() and related interfaces into
__flush_tlb_range() that flushes a range and does not flush the
On Fri, Aug 23, 2019 at 10:11:21AM +0200, Roger Pau Monné wrote:
>On Mon, Aug 19, 2019 at 09:25:25AM +0800, Chao Gao wrote:
>> To create a microcode patch from a vendor-specific update,
>> allocate_microcode_patch() copied everything from the update.
>> It is not efficient. Essentially, we just
39 matches
Mail list logo
