>>> On 21.11.18 at 16:24, wrote:
> On Wed, Nov 21, 2018 at 2:10 AM Jan Beulich wrote:
>> --- 4.20-rc3/arch/x86/entry/entry_64.S
>> +++ 4.20-rc3-x86_64-stack-switch-Xen/arch/x86/entry/entry_64.S
>> @@ -1380,6 +1380,12 @@ ENTRY(nmi)
>> swapgs
>> cld
>> SWITCH_TO_KERNEL_CR3 s
>>> On 21.11.18 at 20:37, wrote:
> * Some of the single-byte versions specify "=q" as the output. AFAICT, there
>was not a legitimate reason to restrict the use of %esi/%edi in the 32-bit
>build. Either way, in 64-bit, it is equivelent to "=r".
I'm confused about the 32-bit part here:
>>> On 21.11.18 at 19:13, wrote:
> As some of you know might already know by discussions on IRC newer
> versions of Xen compiled with LLVM will trigger a page fault shortly
> after boot.
>
> This is due to the usage of opt_bootscrub in init_heap_pages.
> opt_bootscrub is defined in the .init sect
On 21.11.2018 20:55, Razvan Cojocaru wrote:
>> +if ( a == v )
>> +continue;
>> +
>> +/* Pause, synced. */
>> +while ( !a->arch.in_host )
> Why not use a->is_running as a way to know whether the vCPU is
> running?
>
> I think the logic of using v
flight 130680 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
A top level "make build", as used e.g. by osstest, wants to build all
"all" targets in enabled tools subdirectories, which by default also
includes the emulator test harness. The use of, in particular, AVX512
insns in, again in particular, test_x86_emulator.c causes this build to
fail though when t
When MWAIT is disabled, intel_idle refuses to probe.
But it may mis-lead the user by blaming this on the model number:
intel_idle: does not run on family 6 modesl 79
So defer the check for MWAIT until after the model# white-list check succeeds,
and if the MWAIT check fails, tell the user how to f
>>> On 22.11.18 at 10:50, wrote:
> On 21.11.2018 20:55, Razvan Cojocaru wrote:
>>> +if ( a == v )
>>> +continue;
>>> +
>>> +/* Pause, synced. */
>>> +while ( !a->arch.in_host )
>> Why not use a->is_running as a way to know whether the vCPU is
>>
From: Oleksandr Andrushchenko
based frontends. Currently the frontends which implement
similar code for sharing big buffers between frontend and
backend are para-virtualized DRM and sound drivers.
Both define the same way to share grant references of a
data buffer with the corresponding backend w
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Signed-off-by: Oleksandr Andrushchenko
---
sound/xen/Kconfig | 1 +
sound/xen/Makefile | 1 -
sound/xen/xen_snd_front.c
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/Kconfig | 1 +
drivers/gpu/drm/xen/Makefile | 1 -
drivers/gp
While debugging something else, it turned out that staging and/or qemu
can not migrate HVM domUs. qemu runs into an assert when the domU is
about to be migrated with 'xl migrate domU dom0':
qemu-system-i386: block/block-backend.c:903: blk_get_attached_dev_id: Assertion
`!blk->legacy_dev' failed.
On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
> On 11/16/18 7:04 PM, Roger Pau Monné wrote:
> >> +if ( a == v )
> >> +continue;
> >> +
> >> +/* Pause, synced. */
> >> +while ( !a->arch.in_host )
> > Why not use a->is_running as
Commit b1123ea6d3b3 ("mm: balloon: use general non-lru movable page
feature") reworked balloon handling to make use of the general
non-lru movable page feature. The big comment block in
balloon_compaction.h contains quite some outdated information. Let's fix
this.
Cc: Andrew Morton
Cc: Matthew Wi
PG_balloon was introduced to implement page migration/compaction for pages
inflated in virtio-balloon. Nowadays, it is only a marker that a page is
part of virtio-balloon and therefore logically offline.
We also want to make use of this flag in other balloon drivers - for
inflated pages or when on
Right now, pages inflated as part of a balloon driver will be dumped
by dump tools like makedumpfile. While XEN is able to check in the
crash kernel whether a certain pfn is actually backed by memory in the
hypervisor (see xen_oldmem_pfn_is_ram) and optimize this case, dumps of
virtio-balloon, hv-b
Mark inflated and never onlined pages PG_offline, to tell the world that
the content is stale and should not be dumped.
Cc: Xavier Deguillard
Cc: Nadav Amit
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Julien Freche
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsir
Let's use pfn_to_online_page() instead of pfn_to_page() when checking
for saveable pages to not save/restore offline memory sections.
Cc: "Rafael J. Wysocki"
Cc: Pavel Machek
Cc: Len Brown
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Suggested-by: Michal Ho
Right now, pages inflated as part of a balloon driver will be dumped
by dump tools like makedumpfile. While XEN is able to check in the
crash kernel whether a certain pfn is actuall backed by memory in the
hypervisor (see xen_oldmem_pfn_is_ram) and optimize this case, dumps of
other balloon inflate
On Thu, Nov 22, 2018 at 09:50:28AM +, Alexandru Stefan ISAILA wrote:
>
> On 21.11.2018 20:55, Razvan Cojocaru wrote:
> >> +if ( a == v )
> >> +continue;
> >> +
> >> +/* Pause, synced. */
> >> +while ( !a->arch.in_host )
> > Why not use a->is_
The content of pages that are marked PG_offline is not of interest
(e.g. inflated by a balloon driver), let's skip these pages.
In saveable_highmem_page(), move the PageReserved() check to a new
check along with the PageOffline() check to separate it from the
swsusp checks.
Cc: "Rafael J. Wysocki
Mark inflated and never onlined pages PG_offline, to tell the world that
the content is stale and should not be dumped.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S. Tsirkin"
Signed-off-by: David Hildenbran
Mark inflated and never onlined pages PG_offline, to tell the world that
the content is stale and should not be dumped.
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Kairui Song
Cc: Vitaly Kuznetsov
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: "Michael S.
Linux marks pages that are logically offline via a page flag (map count).
Such pages e.g. include pages infated as part of a balloon driver or
pages that were not actually onlined when onlining the whole section.
While the hypervisor usually allows to read such inflated memory, we
basically read a
On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
>> On 11/16/18 7:04 PM, Roger Pau Monné wrote:
+if ( a == v )
+continue;
+
+/* Pause, synced. */
+while ( !a->
flight 75617 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75617/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 75594
jobs:
build-amd64 pass
build-armhf
flight 130635 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Wed, 21 Nov 2018 15:38:16 +0100
Samuel Ortiz wrote:
> Igor,
>
> On Wed, Nov 21, 2018 at 03:15:26PM +0100, Igor Mammedov wrote:
> > On Wed, 21 Nov 2018 07:35:47 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Mon, Nov 19, 2018 at 04:31:10PM +0100, Igor Mammedov wrote:
> > > > On Fri,
On Wed, Nov 21, 2018 at 02:13:00PM +, Sergey Dyasli wrote:
> Now that idle scrub is the default option, all memory is marked as dirty
> and alloc_domheap_pages() will do eager scrubbing by default. This can
> lead to longer Dom0 construction and potentially to a watchdog timeout,
> especially o
The per-arch top level make files don't record any dependencies for the
file, so its mere existence is enough for make to consider it up-to-
date. As of ab3e5f5ff9 ("xsplice, symbols: Implement fast symbol names
-> virtual addresses lookup") the file, however, depends on the
FAST_SYMBOL_LOOKUP conf
On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> > On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
> >> On 11/16/18 7:04 PM, Roger Pau Monné wrote:
> +if ( a == v )
> +continue;
>
flight 130639 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
Refactor p2m_reset_altp2m() so that it can be used to remove
redundant codepaths, fixing the locking while we're at it.
The previous code now replaced by p2m_reset_altp2m(d, i,
ALTP2M_DEACTIVATE) calls did not set p2m->min_remapped_gfn
and p2m->max_remapped_gfn because in those cases the altp2m
id
The logdirty rangesets of the altp2ms need to be kept in sync with the
hostp2m. This means when iterating through the altp2ms, we need to
use the host p2m to clip the rangeset, not the indiviual altp2m's
value.
This change also:
- Documents that the end is non-inclusive
- Calculates an "inclusi
Add logdirty_ranges allocator / deallocator helpers.
p2m_init_logdirty() will not re-allocate if
p2m->logdirty ranges has already been allocated.
Move the rangeset deallocation call from p2m_teardown_hostp2m()
to p2m_free_one() - we will want this to apply to altp2ms
as well.
Signed-off-by: Razva
For now, only do allocation/deallocation; keeping them in sync
will be done in subsequent patches.
Logdirty synchronization will only be done for active altp2ms;
so allocate logdirty rangesets (copying the host logdirty
rangeset) when an altp2m is activated, and free it when
deactivated.
Signed-o
Signed-off-by: Razvan Cojocaru
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
Changes since V8:
- None.
---
xen/include/asm-x86/p2m.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index
When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will fault.
change_range_type() invalidates gfn ranges to lazily change the type
of a range of gfns, and also modifies the logdirty rangesets of that
p2m. At the moment, it clips both down by the hostp2m.
While this will result in correct behavior, it's not entirely efficient,
since invalidated entries outsid
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).
The series introduces p2m_{init,free}_logdirty(), allocates a new
logdirty rangeset for each new altp2m, and propagates (under lock)
changes to
LLVM code generation can attempt to perform a load from a variable in
the next condition of an expression under certain circumstances, thus
turning the following condition:
if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE )
Into:
0x82d080223967 <+103>: cmpl $0x3,0x37
flight 130648 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130648/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 11416ef4a8a41630a61b02e681c9e35d4ea07a7f
baseline version:
freebsd fef1dcc92cf
On Thu, Nov 22, 2018 at 02:58:03AM -0700, Jan Beulich wrote:
> When MWAIT is disabled, intel_idle refuses to probe.
> But it may mis-lead the user by blaming this on the model number:
>
> intel_idle: does not run on family 6 modesl 79
>
> So defer the check for MWAIT until after the model# white-
On 11/21/18 2:09 PM, Razvan Cojocaru wrote:
> Minor improvement; simply improving code quality by using consts
> wherever reasonable.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Razvan Cojocaru
Tamas, I think we need your ack for this?
Thanks,
Razvan
__
On Thu, Nov 22, 2018 at 02:57:19AM -0700, Jan Beulich wrote:
> A top level "make build", as used e.g. by osstest, wants to build all
> "all" targets in enabled tools subdirectories, which by default also
> includes the emulator test harness. The use of, in particular, AVX512
> insns in, again in pa
On Thu, Nov 22, 2018 at 01:03:27PM +0100, Roger Pau Monne wrote:
> LLVM code generation can attempt to perform a load from a variable in
> the next condition of an expression under certain circumstances, thus
> turning the following condition:
>
> if ( system_state < SYS_STATE_active && opt_bootsc
On 22/11/2018 12:03, Roger Pau Monne wrote:
> LLVM code generation can attempt to perform a load from a variable in
> the next condition of an expression under certain circumstances, thus
> turning the following condition:
>
> if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE
On Mon, Nov 12, 2018 at 05:22:45PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v6 03/11] libxl_qmp: Change
> qmp_qemu_check_version to compare version"):
> > This patch makes the function simpler to read. It also add the ability
> > for a caller to tell if QEMU is newer or have the
On Thu, Nov 22, 2018 at 12:24:29PM +, Anthony PERARD wrote:
> On Mon, Nov 12, 2018 at 05:22:45PM +, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH v6 03/11] libxl_qmp: Change
> > qmp_qemu_check_version to compare version"):
> > > This patch makes the function simpler to read. It als
Hi Andrew,
On 11/22/18 12:23 PM, Andrew Cooper wrote:
On 22/11/2018 12:03, Roger Pau Monne wrote:
LLVM code generation can attempt to perform a load from a variable in
the next condition of an expression under certain circumstances, thus
turning the following condition:
if ( system_state < SYS
On 22/11/2018 08:57, Jan Beulich wrote:
> >>> On 21.11.18 at 20:37, wrote:
>> * Some of the single-byte versions specify "=q" as the output. AFAICT, there
>>was not a legitimate reason to restrict the use of %esi/%edi in the 32-bit
>>build. Either way, in 64-bit, it is equivelent to "=r
flight 130683 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On 11/22/18 12:58 PM, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
>> On 11/22/18 12:05 PM, Roger Pau Monné wrote:
>>> On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrote:
On 11/16/18 7:04 PM, Roger Pau Monné wrote:
>> +i
On Wed, Nov 21, 2018 at 06:23:30AM -0700, Jan Beulich wrote:
> >>> On 21.11.18 at 12:51, wrote:
> > On Wed, Nov 21, 2018 at 03:58:34AM -0700, Jan Beulich wrote:
> >> >>> On 21.11.18 at 11:37, wrote:
> >> > On Wed, Nov 21, 2018 at 02:21:36AM -0700, Jan Beulich wrote:
> >> >> >>> On 21.11.18 at 00:
On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> On Thu, Oct 18, 2018 at 08:22:41AM +, Zhao, Yan Y wrote:
> > Hi
> > The background for this patch is that: for some pci device, even it's
> > PCI_INTERRUPT_PIN is not 0, it actually does not support INTx mode, so we
> > should
On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> On Thu, Oct 18, 2018 at 08:22:41AM +, Zhao, Yan Y wrote:
> > Hi
> > The background for this patch is that: for some pci device, even it's
> > PCI_INTERRUPT_PIN is not 0, it actually does not support INTx mode, so we
> > should
>>> On 22.11.18 at 13:38, wrote:
> On 22/11/2018 08:57, Jan Beulich wrote:
>> >>> On 21.11.18 at 20:37, wrote:
>>> * Some of the single-byte versions specify "=q" as the output. AFAICT,
>>> there
>>>was not a legitimate reason to restrict the use of %esi/%edi in the
>>> 32-bit
>>>buil
>>> On 22.11.18 at 13:47, wrote:
> I think the is_hardware_domain part can be dropped from the
> conditional I'm adding. update_paging_mode shouldn't be used to decide
> whether a domain can or cannot have bridges attached. Whether a DomU
> can or cannot have a host bridge assigned should be decid
>>> On 22.11.18 at 13:38, wrote:
> Hi Andrew,
>
> On 11/22/18 12:23 PM, Andrew Cooper wrote:
>> On 22/11/2018 12:03, Roger Pau Monne wrote:
>>> LLVM code generation can attempt to perform a load from a variable in
>>> the next condition of an expression under certain circumstances, thus
>>> turni
On 22/11/2018 13:27, Jan Beulich wrote:
On 22.11.18 at 13:38, wrote:
>> Hi Andrew,
>>
>> On 11/22/18 12:23 PM, Andrew Cooper wrote:
>>> On 22/11/2018 12:03, Roger Pau Monne wrote:
LLVM code generation can attempt to perform a load from a variable in
the next condition of an expressi
>>> On 22.11.18 at 14:31, wrote:
> I think Julien's point is that without explicitly barriers, CPU0's
> update to system_state may not be visible on CPU1, even though the
> mappings have been shot down.
>
> Therefore, from the processors point of view, it did everything
> correctly, and hit a rea
On 22/11/2018 09:58, Jan Beulich wrote:
> When MWAIT is disabled, intel_idle refuses to probe.
> But it may mis-lead the user by blaming this on the model number:
>
> intel_idle: does not run on family 6 modesl 79
>
> So defer the check for MWAIT until after the model# white-list check succeeds,
>
On 22/11/2018 13:19, Jan Beulich wrote:
On 22.11.18 at 13:38, wrote:
>> On 22/11/2018 08:57, Jan Beulich wrote:
>>> >>> On 21.11.18 at 20:37, wrote:
* Some of the single-byte versions specify "=q" as the output. AFAICT,
there
was not a legitimate reason to restrict the u
From: Robin Murphy
If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
lead to such delights as performing cache maintenance on whatever
address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
outside the kernel memory map and goes about as well as expected.
Do
Error reporting for the dma_map_single and dma_map_page operations is
currently a mess. Both APIs directly return the dma_addr_t to be used for
the DMA, with a magic error escape that is specific to the instance and
checked by another method provided. This has a few downsides:
- the error check
Remove the odd sba_{un,}map_single_attrs wrappers, check errors
everywhere, and remove the completly bogus alloc_pages_node call that
uses the dma attributes argument as the node id.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/sba_iommu.c | 71 -
1 fi
The dma-direct code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma-swiotlb.c | 1 -
include/linux/dma-direct.h|
S390 already returns (~(dma_addr_t)0x0) on mapping failures, so we can
switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping
code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/s390/pci/pci_dma.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions
Error handling of the dma_map_single and dma_map_page APIs is a little
problematic at the moment, in that we use different encodings in the
returned dma_addr_t to indicate an error. That means we require an
additional indirect call to figure out if a dma mapping call returned
an error, and a lot o
Arm already returns (~(dma_addr_t)0x0) on mapping failures, so we can
switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping
code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm/common/dmabounce.c | 12 +++---
arch/arm/include/asm/dma-iommu.h | 2 --
arc
The Jazz iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and
let the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/mips/include/asm/jazzdma.h | 6 --
arch/mips/jazz/jazzdma.c|
Hi Jan,
On 11/22/18 1:36 PM, Jan Beulich wrote:
On 22.11.18 at 14:31, wrote:
I think Julien's point is that without explicitly barriers, CPU0's
update to system_state may not be visible on CPU1, even though the
mappings have been shot down.
Therefore, from the processors point of view, it did
From: Robin Murphy
With the overflow buffer removed, we no longer have a unique address
which is guaranteed not to be a valid DMA target to use as an error
token. The DIRECT_MAPPING_ERROR value of 0 tries to at least represent
an unlikely DMA target, but unfortunately there are already SWIOTLB
us
The powerpc iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/iommu.h | 4
arch/powerpc/kernel/dma-iomm
Return DMA_MAPPING_ERROR instead of the magic bad_dma_addr on a dma
mapping failure and let the core dma-mapping code handle the rest.
Remove the magic EMERGENCY_PAGES that the bad_dma_addr gets redirected to.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/pci-calgary_64.c | 29 +++---
Return DMA_MAPPING_ERROR instead of the magic bad_dma_addr on a dma
mapping failure and let the core dma-mapping code handle the rest.
Remove the magic EMERGENCY_PAGES that the bad_dma_addr gets redirected to.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 39 ++---
Sparc already returns (~(dma_addr_t)0x0) on mapping failures, so we can
switch over to returning DMA_MAPPING_ERROR and let the core dma-mapping
code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/sparc/kernel/iommu.c| 12 +++-
arch/sparc/kernel/iommu_common.h | 2 --
Just return DMA_MAPPING_ERROR from __dummy_map_page and let the core
dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mappi
The SBA iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/parisc/sba_iommu.c | 10 +-
1 file changed, 1 insertion(+), 9 de
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel-iommu.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/driver
The CCIO iommu code already returns (~(dma_addr_t)0x0) on mapping
failures, so we can switch over to returning DMA_MAPPING_ERROR and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/parisc/ccio-dma.c | 10 +-
1 file changed, 1 insertion(+), 9 de
Pass the page + offset to the low-level __iommu_map_single helper
(which gets renamed to fit the new calling conventions) as both
callers have the page at hand.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel-iommu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/sba_iommu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/x
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/alpha/kernel/pci_iommu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 7 +++
drivers/iommu/dma-iommu.c | 23 ---
include/linux/dma-iommu.h | 1 -
3 files c
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/ia64/sn/pci/pci_dma.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/p
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Note that the existing code used AMD_IOMMU_MAPPING_ERROR to check from
a 0 return from the IOVA allocator, which is replaced with an explicit
0 as in the implementation and other users
No users left except for vmd which just forwards it. Also switch
dma_mapping_error to an explicit bool return value.
Signed-off-by: Christoph Hellwig
---
drivers/pci/controller/vmd.c | 6 --
include/linux/dma-mapping.h | 13 ++---
2 files changed, 2 insertions(+), 17 deletions(-)
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
On x86, get_gfn_*() and put_gfn() are reference counting pairs. All the
get_gfn_*() functions are called from within CONFIG_X86 sections, but
put_gfn() is stubbed out on ARM.
As a result, the common code reads as if ARM is dropping reference
On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan wrote:
> On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> > On Thu, Oct 18, 2018 at 08:22:41AM +, Zhao, Yan Y wrote:
> > > Hi
> > > The background for this patch is that: for some pci device, even it's
> > > PCI_INTERRUPT_PIN
On Thu, Nov 22, 2018 at 01:40:23PM +0200, Razvan Cojocaru wrote:
> Signed-off-by: Razvan Cojocaru
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi,
On 10/8/18 7:33 PM, Julien Grall wrote:
Julien Grall (16):
xen/arm: Introduce helpers to get/set an MFN from/to an LPAE entry
xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid
entry
xen/arm: guest_walk_tables: Switch the return to bool
xen/arm: p2m: Introduc
>>> On 22.11.18 at 14:58, wrote:
> On 22/11/2018 13:19, Jan Beulich wrote:
> On 22.11.18 at 13:38, wrote:
>>> On 22/11/2018 08:57, Jan Beulich wrote:
>>> On 21.11.18 at 20:37, wrote:
> @@ -79,31 +72,27 @@ static always_inline unsigned long __cmpxchg(
> switch ( size )
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
Seemingly, a majority of users either override the helpers anyway, or have an
mfn_t in their hands.
Update the API, and adjust all users to match. In some places, use the
unsigned long variant in places where we are interacting with an exter
On Thu, Nov 22, 2018 at 12:02:29PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Use page directory based shared buffer implementation
> now available as common code for Xen frontend drivers.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/Kco
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
share_xen_page_with_guest() is a common API. Use it directly rather than
wrapping it with unnecessary boilerplate.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC:
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
* Reflow some lines to remove unnecessary line breaks.
* Factor out the gnttab_get_frame_gfn() calculation. Neither x86 nor ARM
builds seem to be able to fold the two calls, and the resulting code is far
easier to follow.
Signed-
On Wed, Nov 21, 2018 at 04:49:06PM +, Anthony PERARD wrote:
> On Fri, Nov 16, 2018 at 12:14:43PM +, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH v6 08/11] libxl: QEMU startup sync based on
> > QMP"):
> > > +LOGD(DEBUG, ev->domid, ".. instead, got: %s",
> > > +
>>> On 20.11.18 at 15:37, wrote:
> The final remnanat of PVRDTSCP is that we would emulate RDTSCP even on
> hardware which lacked the instruction. RDTSCP is available on almost all
> 64-bit x86 hardware.
>
> Remove this emulation, drop the TSC_MODE_PVRDTSCP constant, and allow RDTSCP
> in a PV g
1 - 100 of 186 matches
Mail list logo
