>>> On 29.11.18 at 18:33, wrote:
> On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -742,6 +742,16 @@ static int msi_capability_init(struct pc
>>
>> *desc = entry;
>> /* Restore the original MSI enabled bits */
On Thu, Nov 29, 2018 at 10:46:05AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 12:28:46PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:02:25PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:14PM +0800, Chao Gao wrote:
>> >> diff --git a/xen/arch/x86/microcode.c b
On Thu, Nov 29, 2018 at 10:56:53AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 29, 2018 at 12:43:25PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:22:09PM +0100, Roger Pau Monné wrote:
>> >On Wed, Nov 28, 2018 at 01:34:16PM +0800, Chao Gao wrote:
>> >> This patch ports microcode improvement
>>> On 29.11.18 at 18:44, wrote:
> On Thu, Nov 08, 2018 at 09:05:45AM -0700, Jan Beulich wrote:
>> --- a/xen/arch/x86/efi/Makefile
>> +++ b/xen/arch/x86/efi/Makefile
>> @@ -5,7 +5,11 @@ CFLAGS += -fshort-wchar
>>
>> boot.init.o: buildid.o
>>
>> +EFIOBJ := boot.init.o compat.o runtime.o
>> +
>
flight 130840 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 130142
test-amd64-i386-xl-qe
flight 130842 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
130373
test-amd64-i386-xl
>>> On 29.11.18 at 20:20, wrote:
> In almost all cases, Xen and libxc will agree on the featureset length,
> because they are built from the same source.
>
> However, there are circumstances (e.g. security hotfixes) where the featureset
> gets longer and dom0 will, after installing updates, be ru
>>> On 29.11.18 at 20:20, wrote:
> get_cpuid_domain_info() has two conflicting return styles - either -error for
> local failures, or -1/errno for hypercall failures. Switch to consistently
> use -error.
>
> While fixing the xc_get_cpu_featureset(), take the opportunity to remove the
> redundanc
>>> On 30.11.18 at 08:55, wrote:
> On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
>>On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
>>> On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>>> >On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
>>> >>
>>> On 30.11.18 at 09:57, wrote:
> On Thu, Nov 29, 2018 at 10:46:05AM +0100, Roger Pau Monné wrote:
>>On Thu, Nov 29, 2018 at 12:28:46PM +0800, Chao Gao wrote:
>>> It is better that all CPUs have the same microcode revision.
>>>
>>> Linux kernel rejects late microcode update if finding some CPUs
The init function doesn't do anything at all, so we
just omit it.
Cc: sstabell...@kernel.org
Cc: anthony.per...@citrix.com
Cc: xen-devel@lists.xenproject.org
Cc: peter.mayd...@linaro.org
Signed-off-by: Mao Zhongyi
Signed-off-by: Zhang Shengju
Acked-by: Anthony PERARD
---
hw/xen/xen_backend.c
v3 -> v2:
- rebase to the HEAD
- use SysBusDevice *sbd variable in patch15
v2 -> v1:
- SYS_BUS_DEVICE(dev) was used in a function several
times, so use a variable 'sbd' to replace it, like:
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
- remove the xen_sysdev_init() function
- drop the patch21 in
>>> On 29.11.18 at 23:43, wrote:
> One other comment about this patch (which IIRC was raised by Andrew on
> an earlier version) is that it may be worth to stop timer calibration. I
> am pretty sure we've seen deadlocks, which is why we ended up disabling
> it during microcode updates.
I recall th
At 07:53 -0700 on 29 Nov (1543477992), Jan Beulich wrote:
> We've had more than one report of host crashes after failed migration,
> and in at least one case we've had a hint towards a too far shrunk
> shadow allocation pool. Instead of just checking the pool for being
> empty, check whether the po
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and, instead, adds explicit flushing at the
end of the loops in the iommu_map/unmap() wrapper functions.
Because VT-d currently performs two different types of flush dependent upon
whether a PTE
Paul Durrant (2):
amd-iommu: add flush iommu_ops
iommu: elide flushing for higher order map/unmap operations
xen/drivers/passthrough/amd/iommu_map.c | 114 --
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +
xen/drivers/passthrough/arm/smmu.c|
The iommu_ops structure contains two methods for flushing: 'iotlb_flush' and
'iotlb_flush_all'. This patch adds implementations of these for AMD IOMMUs.
The iotlb_flush method takes a base DFN and a (4k) page count, but the
flush needs to be done by page order (i.e. 0, 9 or 18). Because a flush
op
flight 75627 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-jessie-netboot-pvgrub 10 debian-di-install fail REGR. vs.
75618
Tests which
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The alloca
>>> On 29.11.18 at 18:11, wrote:
> This errata affect the values read from the BAR registers, and could
> render vPCI (and by extension PVH Dom0 unusable).
>
> HSE43 is a Haswell erratum where a non-BAR register is implemented at
> the position where the first BAR of the device should be found in
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The alloca
On Fri, Nov 30, 2018 at 01:52:39AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 18:33, wrote:
> > On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
> >> --- a/xen/arch/x86/msi.c
> >> +++ b/xen/arch/x86/msi.c
> >> @@ -742,6 +742,16 @@ static int msi_capability_init(struct pc
> >>
> >
> On Nov 23, 2018, at 5:14 PM, George Dunlap wrote:
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e498435e16..a370de54ed 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1135,6 +1135,8 @@ typedef struct {
> const c
On 30/11/2018 10:45, Paul Durrant wrote:
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and, instead, adds explicit flushing at the
> end of the loops in the iommu_map/unmap() wrapper functions.
>
> Because VT-d currently performs two diff
> On Nov 28, 2018, at 3:32 PM, Wei Liu wrote:
>
> On Fri, Nov 23, 2018 at 05:14:56PM +, George Dunlap wrote:
>> QEMU_USER_BASE allows a user to specify the UID to use when running
>> the devicemodel for a specific domain number. Unfortunately, this is
>> not really practical: It requires n
On 30/11/2018 10:45, Paul Durrant wrote:
> diff --git a/xen/drivers/passthrough/amd/iommu_map.c
> b/xen/drivers/passthrough/amd/iommu_map.c
> index 04cb7b3182..c05b042821 100644
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -631,6 +631,54 @@ i
On 30/11/2018 09:18, Jan Beulich wrote:
On 29.11.18 at 20:20, wrote:
>> In almost all cases, Xen and libxc will agree on the featureset length,
>> because they are built from the same source.
>>
>> However, there are circumstances (e.g. security hotfixes) where the
>> featureset
>> gets long
> -Original Message-
> From: Andrew Cooper
> Sent: 30 November 2018 13:04
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Suravee Suthikulpanit ; Brian Woods
> ; Jan Beulich ; Wei Liu
> ; Roger Pau Monne
> Subject: Re: [PATCH 1/2] amd-iommu: add flush iommu_ops
>
> On 30/11/2018
On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
> On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
>> On 29/11/2018 15:32, Kirill A. Shutemov wrote:
>>> On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrot
On 30/11/2018 09:23, Jan Beulich wrote:
On 29.11.18 at 20:20, wrote:
>> get_cpuid_domain_info() has two conflicting return styles - either -error for
>> local failures, or -1/errno for hypercall failures. Switch to consistently
>> use -error.
>>
>> While fixing the xc_get_cpu_featureset(), t
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
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
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
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
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
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 --
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
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
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 ++---
Remove the odd sba_{un,}map_single_attrs wrappers, check errors
everywhere.
Signed-off-by: Christoph Hellwig
---
arch/ia64/hp/common/sba_iommu.c | 73 +
1 file changed, 29 insertions(+), 44 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/
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|
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
---
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
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
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|
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
No users left except for vmd which just forwards it.
Signed-off-by: Christoph Hellwig
---
drivers/pci/controller/vmd.c | 6 --
include/linux/dma-mapping.h | 7 ---
2 files changed, 13 deletions(-)
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index e50b0b5815
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 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
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
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
Currently dma_mapping_error returns a boolean as int, with 1 meaning
error. This is rather unusual and many callers have to convert it to
errno value. The callers are highly inconsistent with error codes
ranging from -ENOMEM over -EIO, -EINVAL and -EFAULT ranging to -EAGAIN.
Return -ENOMEM which
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(-)
On Thu, Nov 29, 2018 at 07:20:00PM +, Andrew Cooper wrote:
> Andrew Cooper (2):
> tools/libxc: Fix issues with libxc and Xen having different featureset
> lengths
> tools/libxc: Fix error handling in get_cpuid_domain_info()
With Jan's comments addressed:
Acked-by: Wei Liu
_
On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
> >> On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shut
On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
> On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
>> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
>>> On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> On Thu
On 30/11/2018 12:01, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from pvcal
flight 130849 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130849/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd b1f31943cb61465b80f786de48501e2fb03e1b61
baseline version:
freebsd 8894b8e3175
flight 130843 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130843/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-libv
flight 130873 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130873/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
> -Original Message-
> From: Andrew Cooper
> Sent: 30 November 2018 12:49
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Suravee Suthikulpanit
> ; Brian Woods ; Jan
> Beulich ; Kevin Tian ; Wei Liu
> ; Roger Pau Monne
> Subject: Re: [PATCH 2
On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
> On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
>> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
>>> On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> On Thu
Hi Jan, hi Juergen,
I'm trying again this week to install Xen on a OVH server
(https://www.ovh.com/fr/serveurs_dedies/infra/1801eg02.xml).
It is still impossible to boot Xen with the option "dom0_mem=1G,max:1G"
(boot : EFI->xen).
I have tried with Debian 9 stable/stretch :
- grub2 (2.02~bet
The ITS driver was added in Xen 4.10 as a technical preview feature.
However, it is required in order to boot Xen as Thunder-X because
PCI devices don't support legacy interrupt.
So enable CONFIG_ITS in our Xen build.
Signed-off-by: Julien Grall
---
ts-xen-build | 4
1 file changed, 4 inse
flight 130844 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 129996
> On Nov 28, 2018, at 4:43 PM, Ian Jackson wrote:
>
> George Dunlap writes ("[PATCH 7/9] libxl: Make killing of device model
> asynchronous"):
>> Or at least, give it an asynchronous interface so that we can make it
>> actually asynchronous in subsequent patches.
>>
>> Create state structures
> On Nov 30, 2018, at 4:12 PM, George Dunlap wrote:
>
>
>
>> On Nov 28, 2018, at 4:43 PM, Ian Jackson wrote:
>>
>> George Dunlap writes ("[PATCH 7/9] libxl: Make killing of device model
>> asynchronous"):
>>> Or at least, give it an asynchronous interface so that we can make it
>>> actuall
George Dunlap writes ("Re: [PATCH 7/9] libxl: Make killing of device model
asynchronous"):
> On Nov 28, 2018, at 4:43 PM, Ian Jackson wrote:
> > Conversely it would be nice to say somewhere
> > that ddms->callback may be called reentrantly.
>
> What do you mean by reentrantly? That libxl__destr
On Fri, Nov 30, 2018 at 02:53:50PM +, Hans van Kranenburg wrote:
> On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
> > On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
> >> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen
George Dunlap writes ("Re: [PATCH 7/9] libxl: Make killing of device model
asynchronous"):
> It looks cleaner to me to have *something* there than not, just to visually
> make it clear that it has nothing to do with the previous function.
That's OK by me.
Ian.
_
On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
> Which, on x86, requires fiddling with the INTx bit in PCI config space,
> since for internally used MSI we can't delegate this to Dom0.
>
> ns16550_init_postirq() also needs (benign) re-ordering of its
> operations.
>
> Signed-off-by:
> On Nov 28, 2018, at 4:56 PM, Ian Jackson wrote:
>
>> if (!xs_rm(CTX->xsh, XBT_NULL, path))
>> LOGD(ERROR, domid, "xs_rm failed for %s", path);
>>
>> -/* We should try to destroy the device model anyway. */
>> -rc = kill_device_model(gc,
>> - GCSPRINTF("/local/
On 11/30/18 4:46 AM, Jan Beulich wrote:
On 29.11.18 at 23:43, wrote:
>> One other comment about this patch (which IIRC was raised by Andrew on
>> an earlier version) is that it may be worth to stop timer calibration. I
>> am pretty sure we've seen deadlocks, which is why we ended up disabling
On Fri, 30 Nov 2018 at 09:39, Mao Zhongyi
wrote:
>
> v3 -> v2:
>
> - rebase to the HEAD
> - use SysBusDevice *sbd variable in patch15
> Mao Zhongyi (21):
> musicpal: Convert sysbus init function to realize function
> block/noenand: Convert sysbus init function to realize function
> char/grl
On Fri, Nov 30, 2018 at 12:53:20PM +, George Dunlap wrote:
>
>
> > On Nov 28, 2018, at 3:32 PM, Wei Liu wrote:
> >
> > On Fri, Nov 23, 2018 at 05:14:56PM +, George Dunlap wrote:
> >> QEMU_USER_BASE allows a user to specify the UID to use when running
> >> the devicemodel for a specific
For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
supports the instruction, but the guest may have not have rdtscp in its
featureset. Bring the vmexit handlers in line with the main emulator
behaviour by optionally handing back #UD.
Next on the AMD side, if RDTSCP actually
Sadly, a lone:
(XEN) emulate.c:156:d2v0 __get_instruction_length_from_list: Mismatch between
expected and actual instruction: eip = f804564139c0
on the console is of no use trying to identify what went wrong. Dump as much
state as we can to help identify what went wrong.
Reported-by: Pau
For some reason (on EPYC at least) we've gained a regression into master
whereby VMs are defaulting to one of the emulated TSC modes. This may be Xen
coming to the conclusion that there isn't a reliable TSC. Combined with a
debug Xen, this breaks RDTSCP completely.
With this series in place and
Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
> It is agreed that tmem can be removed from xen.git. See the thread starting
>
>
> from .
Those are notes from some phone call amongst industry stakeholders.
None of
Wei Liu writes ("[PATCH v2 1/3] tools: remove tmem code and commands"):
> Remove all tmem related code in libxc.
>
> Leave some stubs in libxl in case anyone has linked to those functions
> before the removal.
>
> Remove all tmem related commands in xl, all tmem related code in other
> utilities
On Fri, Nov 30, 2018 at 05:07:19PM +, Andy Cooper wrote:
> Sadly, a lone:
>
> (XEN) emulate.c:156:d2v0 __get_instruction_length_from_list: Mismatch
> between expected and actual instruction: eip = f804564139c0
>
> on the console is of no use trying to identify what went wrong. Dump as
GICv2 and GICv3 supports up to 1020 interrupts. However, the value computed
from GICD_TYPER.ITLinesNumber can be up to 1024. On GICv3, we will end up to
write in reserved registers that are right after the IROUTERs one as the
value is not capped early enough.
Cap the number of interrupts as soon a
On Fri, Nov 30, 2018 at 05:07:20PM +, Andy Cooper wrote:
> For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
> supports the instruction, but the guest may have not have rdtscp in its
> featureset. Bring the vmexit handlers in line with the main emulator
> behaviour by op
Hi,
Below a list of backport candidate for Arm.
For Xen 4.10+ to handle correctly SMC call parameters and result
35fc608612 xen/arm: smccc-1.1: Make return values unsigned long
fa7974f743 xen/arm: smccc-1.1: Handle function result as parameters
For Xen 4.9+ to avoid Dom0 crash when
flight 130877 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130877/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 11/30/18 5:21 PM, Kirill A. Shutemov wrote:
> On Fri, Nov 30, 2018 at 02:53:50PM +, Hans van Kranenburg wrote:
>> On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
>>> On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
>
On 11/30/18 6:01 AM, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from pvcall
Memory onlining should always be handled by user space, because only user
space knows which use cases it wants to satisfy. E.g. memory might be
onlined to the MOVABLE zone even if it can never be removed from the
system, e.g. to make usage of huge pages more reliable.
However to implement such rul
Let's introduce new types for different kinds of memory blocks and use
them in existing code. As I don't see an easy way to split this up,
do it in one hunk for now.
acpi:
Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.
Properly change the type when trying to add memor
This is the second approach, introducing more meaningful memory block
types and not changing online behavior in the kernel. It is based on
latest linux-next.
As we found out during dicussion, user space should always handle onlining
of memory, in any case. However in order to make smart decisions
Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device
memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No
functional change.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Martin Schwidefsky
Cc: Heiko
We now have proper types for all users, we can drop this one.
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Pavel Tatashin
Cc: Stephen Rothwell
Cc: Andrew Banman
Cc: "mike.tra...@hpe.com"
Cc: Oscar Salvador
Cc: Dave Hansen
Cc: Michal Hocko
Cc: Mich
On Fri, Nov 30, 2018 at 05:09:42PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
> > It is agreed that tmem can be removed from xen.git. See the thread starting
> >
> >
> > from .
>
>
On Fri, Nov 30, 2018 at 02:22:08PM +0100, Christoph Hellwig wrote:
> 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
On Fri, Nov 30, 2018 at 5:23 AM Christoph Hellwig wrote:
>
> Error reporting for the dma_map_single and dma_map_page operations is
> currently a mess. [..]
I don't see anything objectionable there, but it's not like I checked
any of the context of the patches. For all I know there are odd corner
Hello Andre,
Please see my comments below:
On 23.11.18 14:18, Andre Przywara wrote:
Fundamentally there is a semantic difference between edge and level
triggered IRQs: When the guest has handled an *edge* IRQ (EOIed so
the LR's state goes to 0), this is done and dusted, and Xen doesn't
need to
flight 130847 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130847/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 130804
build-
There is a guard hole at the beginning of kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
We do not state the reserved range directly, but calculate it relative
to other entities: direct mapping and user space ranges.
The calculation got broken by recent change in kern
There's a couple fixes for the recent LDT remap placement change.
The first patch fixes crash when kernel booted as Xen dom0.
The second patch fixes address space markers in dump_pagetables output.
It's purely cosmetic change, backporting to the stable tree is optional.
v2:
- Fix typo
Kirill A
1 - 100 of 141 matches
Mail list logo
