On 1/29/19 16:11, Jan Beulich wrote:
On 29.01.19 at 14:47, wrote:
>> On 1/29/19 10:46, Jan Beulich wrote:
>> Norbert Manthey 01/29/19 9:35 AM >>>
I am aware that both version use the same base array, and access it via
different macros, which essentially partition the array base
On 29/01/2019 18:08, osstest service owner wrote:
> flight 132544 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/132544/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemut-stubdo
Don't allow memory to be added above the allowed maximum allocation
limit set by Xen.
Trying to do so would result in cases like the following:
[ 584.559652] [ cut here ]
[ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129
xen_alloc_pte+0x1c7/0x390(
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
parameter.
The
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added when adding PCI devices due
Dropped in favor of https://lkml.org/lkml/2019/1/29/910
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hell
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecombine while mmaping.
>> This fixes mismatc
>>> On 29.01.19 at 21:43, wrote:
> On 23/01/2019 11:35, Jan Beulich wrote:
> On 21.01.19 at 16:37, wrote:
>>> --- a/xen/arch/x86/guest/pvh-boot.c
>>> +++ b/xen/arch/x86/guest/pvh-boot.c
>>> @@ -38,12 +38,20 @@ static const char *__initdata pvh_loader = "PVH
> Directboot";
>>> static void __
On 2019/1/26 1:48, Jan Beulich wrote:
On 20.12.18 at 14:14, wrote:
>> The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
>> counter MSRs, hardware configuration MSR, MMIO configuration base address
>> MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to
>>> On 29.01.19 at 20:07, wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -40,7 +40,11 @@
> #undef virt_to_mfn
> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
>
> -#ifndef CONFIG_PV_SHIM_EXCLUSIVE
> +#ifdef CONFIG_PV_SHIM_EXCLUSIVE
> +/* Tolerate "pv-shim" being pas
On 30/01/2019 09:57, Jan Beulich wrote:
On 29.01.19 at 20:07, wrote:
>> --- a/xen/arch/x86/pv/shim.c
>> +++ b/xen/arch/x86/pv/shim.c
>> @@ -40,7 +40,11 @@
>> #undef virt_to_mfn
>> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
>>
>> -#ifndef CONFIG_PV_SHIM_EXCLUSIVE
>> +#ifdef CONFIG_PV_
On 2019/1/29 19:11, Jan Beulich wrote:
Pu Wen 12/20/18 2:16 PM >>>
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1973,6 +1973,8 @@ static unsigned int calc_ler_msr(void)
return MSR_IA32_LASTINTFROMIP;
}
break;
+case X86_VENDOR_HYGON:
+return MSR_IA32_LASTINTFROMIP;
Wit
On 30/01/2019 10:01, Andrew Cooper wrote:
> On 30/01/2019 09:57, Jan Beulich wrote:
> On 29.01.19 at 20:07, wrote:
>>> --- a/xen/arch/x86/pv/shim.c
>>> +++ b/xen/arch/x86/pv/shim.c
>>> @@ -40,7 +40,11 @@
>>> #undef virt_to_mfn
>>> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
>>>
>>> -#i
>>> On 30.01.19 at 11:01, wrote:
> On 30/01/2019 09:57, Jan Beulich wrote:
> On 29.01.19 at 20:07, wrote:
>>> --- a/xen/arch/x86/pv/shim.c
>>> +++ b/xen/arch/x86/pv/shim.c
>>> @@ -40,7 +40,11 @@
>>> #undef virt_to_mfn
>>> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
>>>
>>> -#ifndef CO
>>> On 30.01.19 at 10:52, wrote:
> On 2019/1/26 1:48, Jan Beulich wrote:
> On 20.12.18 at 14:14, wrote:
>>> The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
>>> counter MSRs, hardware configuration MSR, MMIO configuration base address
>>> MSR, MPERF/APERF MSRs) as AMD
flight 132615 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 132424
version t
Hello,
The following series contains fixes that should be considered for 4.12.
I'm not sure whether patches 6, 7 and 8 should be aimed at 4.12, they
contain changes to the p2m code that could affect HVM guests. Note that
without those changes a PVH dom0 running on AMD hardware will be unable
to c
Current code in shadow_enable will allocate a shadow pool of 4MB
regardless of the values of sh_min_allocation or
shadow_min_acceptable_pages, which means that calls to
shadow_alloc_p2m_page can fail even after the check and allocation
done just above.
Fix this by always checking that the pool is
The assert was originally added to make sure that higher order
regions (> PAGE_ORDER_4K) could not be used to bypass the
mmio_ro_ranges check performed by p2m_type_to_flags.
This however is already checked in set_mmio_p2m_entry, which makes
sure that higher order mappings don't overlap with mmio_r
Due to the recent changes in the iommu mapping logic, the start
addresses provided need to be aligned to the order intended to be
mapped.
dom0 PVH domain builder didn't take this into account when populating
the p2m, fix this by making sure the order is chosen so that the start
address is aligned
Reserved memory ranges below 1MB on a PVH dom0 are added to the HAP
page tables, but due to this being done before setting up the IOMMU
the non RAM regions in those areas are not added to the IOMMU page
tables. Fix this by making sure any reserved regions below 1MB are
added to the IOMMU page table
Current npt and shadow code to get an entry will always return
INVALID_MFN for foreign entries. Allow to return the entry mfn for
foreign entries, like it's done for grant table entries.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xe
There have been several reports of the dom0 builder running out of
memory when buildign a PVH dom0 without havingf specified a dom0_mem
value. Print a warning message if dom0_mem is not set to a fixed value
when booting in PVH mode.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew C
So that it can be shared by both ept, npt and shadow code, instead of
duplicating it.
No change in functionality intended.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Paul Durrant
---
xen/arch/x86/
So that the specific handling can be removed from
atomic_write_ept_entry and be shared with npt and shadow code.
This commit also removes the check that prevent non-ept PVH dom0 from
mapping foreign pages.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
On 2019/1/29 19:15, Jan Beulich wrote:
Pu Wen 12/20/18 2:16 PM >>>
>> --- a/xen/arch/x86/xstate.c
>> +++ b/xen/arch/x86/xstate.c
>> @@ -369,7 +369,7 @@ void xrstor(struct vcpu *v, uint64_t mask)
>> unsigned int faults, prev_faults;
> >
>> /*
>> - * AMD CPUs don't save/restore FDP/FIP/FO
> On Jan 30, 2019, at 1:22 AM, Juergen Gross wrote:
>
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + /*
> + * Don't allow adding memory not in E820 map while
> + * booting the system. Once the balloon driver is up
> + * it
Hello Andrii,
2019年1月29日(火) 22:30 Andrii Anisov :
> Hello Jairo,
>
> On 29.01.19 17:30, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
> > (XEN) Checking for initrd in /chosen
> > (XEN) RAM: 4800 - 7fff
> > (XEN) RAM: 0006 - 00063fff
> > (XEN) RAM: 00
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.
>>> On 30.01.19 at 11:07, wrote:
> On 30/01/2019 10:01, Andrew Cooper wrote:
>> On 30/01/2019 09:57, Jan Beulich wrote:
>> On 29.01.19 at 20:07, wrote:
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -40,7 +40,11 @@
#undef virt_to_mfn
#define virt_to_mf
Adding Anthony who likely knows more about all this since it's closely
related to QEMU.
On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote:
> Hello,
>
> Given the following vm.cfg file:
>
> name="vm"
> type="hvm"
>
> vcpus=4
> memory=1024
>
> firmware_override="/root/xen-syms"
>
>
>>> On 30.01.19 at 09:06, wrote:
> On 1/29/19 16:11, Jan Beulich wrote:
> On 29.01.19 at 14:47, wrote:
>>> On 1/29/19 10:46, Jan Beulich wrote:
>>> Norbert Manthey 01/29/19 9:35 AM >>>
> I am aware that both version use the same base array, and access it via
> different macros, w
On 30/01/2019 01:21, Peng Fan wrote:
Hi Julien
Hi Peng,
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 2019年1月29日 23:57
To: Peng Fan ; sstabell...@kernel.org; jgr...@suse.com
Cc: xen-devel@lists.xenproject.org; Andre Przywara
Subject: Re: [PATCH for-4.12]
flight 132575 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 132422
test-amd64-i386-xl
On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote:
> Hello,
>
> Given the following vm.cfg file:
>
> name="vm"
> type="hvm"
>
> vcpus=4
> memory=1024
>
> firmware_override="/root/xen-syms"
>
> kernel="/boot/vmlinuz-4.4-xen"
> ramdisk="/boot/initrd-4.4.0+10.img"
>
> cmdline="consol
Hi
Replying to this thread again.
On 22/01/2019 10:54, Julien Grall wrote:
Hi Peng,
The commit title is a bit confusing. It suggests that all interrupts should be
deactivated at boot, however you are only deactivating the SGIs.
On 1/22/19 2:35 AM, Peng Fan wrote:
On i.MX8, we implemented p
On Wed, Jan 30, 2019 at 12:25:20PM +0100, Roger Pau Monné wrote:
> Adding Anthony who likely knows more about all this since it's closely
> related to QEMU.
>
> On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote:
> > Hello,
> >
> > Given the following vm.cfg file:
> >
> > name="vm"
>
Hi,
On 30/01/2019 20:23, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
My e-mail client thinks the e-mail was sent from the future. Can you make sure
your timezone is set correctly?
[ 0.682996] CPU features: detected feature: Kernel page table isolation
(KPTI)
(XEN) p2m.c:1844: d0v1: Fai
On 30/01/2019 11:25, Roger Pau Monné wrote:
> Adding Anthony who likely knows more about all this since it's closely
> related to QEMU.
>
> On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote:
>> Hello,
>>
>> Given the following vm.cfg file:
>>
>> name="vm"
>> type="hvm"
>>
>> vcpus=4
>>
On 30/01/2019 11:59, Wei Liu wrote:
> On Tue, Jan 29, 2019 at 07:49:51PM +, Andrew Cooper wrote:
>> Hello,
>>
>> Given the following vm.cfg file:
>>
>> name="vm"
>> type="hvm"
>>
>> vcpus=4
>> memory=1024
>>
>> firmware_override="/root/xen-syms"
>>
>> kernel="/boot/vmlinuz-4.4-xen"
>> ramdisk="
On Wed, Jan 30, 2019 at 11:36:39AM +0100, Roger Pau Monne wrote:
> Due to the recent changes in the iommu mapping logic, the start
> addresses provided need to be aligned to the order intended to be
> mapped.
>
Can you reference some commits here? What would happen if the address is
not aligned?
>>> On 29.01.19 at 19:55, wrote:
> On 29/01/2019 18:49, osstest service owner wrote:
>> flight 132484 xen-4.9-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/132484/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could no
On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote:
> >> There are at least two bugs here.
> >>
> >> 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH
> >> entrypoint must not mandate its existence, because there are releases of
> >> the domain builder which don't provide
There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether we use FUNC or CODE,
depends on whether ENDP
Here, we change all assembly code which is marked using END (and not
ENDPROC). We switch all these to appropriate new markings SYM_CODE_START
and SYM_CODE_END.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [xen bits]
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@k
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.
Sign
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.
So introduce macros with clear use to annotate assembly as follows:
a) Support macr
Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros to have:
8 OBJECT LOCAL DEFAULT6 gdt
000832 OBJECT LOCAL DEFAULT6 gdt_start
0028 0 OBJECT LOCAL DEFAULT6 gdt_end
0028 256 OBJECT LOCAL DEFAULT6 early_stack
0128 0 OBJECT LOCAL DEFAU
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END appropriatelly too.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [
On 30/01/2019 12:43, Jan Beulich wrote:
On 29.01.19 at 19:55, wrote:
>> On 29/01/2019 18:49, osstest service owner wrote:
>>> flight 132484 xen-4.9-testing real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/132484/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and
Hi Julien
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年1月30日 20:06
> To: Peng Fan ; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: [PATCH] arm: gic-v3: clear GICR active interrupts
>
> Hi
>
> Replying
On Tue, Jan 29, 2019 at 12:27:30PM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:50PM +0800, Chao Gao wrote:
>> Currently, microcode_update_lock and microcode_mutex prevent cores
>> from updating microcode in parallel. Below changes are made to support
>> parallel microcode update on
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Peng Fan
> Sent: 2019年1月30日 21:24
> To: Julien Grall ; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: [Xen-devel] [PATCH] arm: gic-v3: clear
On Wed, Jan 30, 2019 at 12:46:45PM +, Wei Liu wrote:
> On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote:
> > >> There are at least two bugs here.
> > >>
> > >> 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH
> > >> entrypoint must not mandate its existence, because
On Mon 2019-01-21 10:04:08, Mike Rapoport wrote:
> As all the memblock allocation functions return NULL in case of error
> rather than panic(), the duplicates with _nopanic suffix can be removed.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Greg Kroah-Hartman
> ---
> arch/arc/kernel/unwind.c
On Tue, Jan 29, 2019 at 11:37:12AM +0100, Roger Pau Monné wrote:
>On Mon, Jan 28, 2019 at 03:06:49PM +0800, Chao Gao wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> Before you read any further: the early loading method is still the
>> preferred one and you should
Hi,
On 30/01/2019 13:36, Peng Fan wrote:
Each ICACTIVER0 registers hold the active bit for 32 interrupts.
However, this code assumes the register only hold 4 interrupts. So
this will write to unwanted area.
There are only 16 SGIs, so it fits in one write to ICACTIVER0. As
wrote above, you also
On 30/01/2019 14:38, Wei Liu wrote:
> On Wed, Jan 30, 2019 at 12:46:45PM +, Wei Liu wrote:
>> On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote:
> There are at least two bugs here.
>
> 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH
> entrypoint must
On Wed, Jan 30, 2019 at 02:49:52PM +0100, Juergen Gross wrote:
> On 30/01/2019 14:38, Wei Liu wrote:
> > On Wed, Jan 30, 2019 at 12:46:45PM +, Wei Liu wrote:
> >> On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote:
> > There are at least two bugs here.
> >
> > 1) RSDP was
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年1月30日 21:49
> To: Peng Fan ; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: [PATCH] arm: gic-v3: clear GICR active interrupts
>
> Hi,
>
> On 30/01/2019 13:
On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_F
flight 132618 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132618/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The
guest (xen) will fall back to scanning if necessary.
Reported-by: Andrew Cooper
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/pvh-boot.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arc
On 30/01/2019 13:55, Wei Liu wrote:
> RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The
> guest (xen) will fall back to scanning if necessary.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xe
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because we also need to support A72 Cluster reboot without
affecting A53 Cluster.
The gic-v3 controller is configured with EOImode to 1, so during
On Wed, Jan 30, 2019 at 12:37:28PM +, Wei Liu wrote:
> On Wed, Jan 30, 2019 at 11:36:39AM +0100, Roger Pau Monne wrote:
> > Due to the recent changes in the iommu mapping logic, the start
> > addresses provided need to be aligned to the order intended to be
> > mapped.
> >
>
> Can you referen
On 30/01/2019 14:55, Wei Liu wrote:
> RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The
> guest (xen) will fall back to scanning if necessary.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Wei Liu
Release-acked-by: Juergen Gross
Juergen
__
On 30/01/2019 11:06, Jan Beulich wrote:
On 30.01.19 at 11:01, wrote:
>> On 30/01/2019 09:57, Jan Beulich wrote:
>> On 29.01.19 at 20:07, wrote:
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -40,7 +40,11 @@
#undef virt_to_mfn
#define virt_to_mfn(v
On 30/01/2019 15:09, Juergen Gross wrote:
> On 30/01/2019 11:06, Jan Beulich wrote:
> On 30.01.19 at 11:01, wrote:
>>> On 30/01/2019 09:57, Jan Beulich wrote:
>>> On 29.01.19 at 20:07, wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -40,7 +40,11 @@
>>
>>> On 30.01.19 at 14:51, wrote:
> On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -1474,6 +1474,22 @@ int pci_restore_msi_state(struct pci_dev *pdev)
>> return 0;
>> }
>>
>> +int msi_msix_set_enable(
Anthony PERARD writes ("[PATCH for-4.12] libxl: When restricted, start QEMU
paused"):
> [stuff]
Thanks for this. I think the code looks right but to make it easier
to understand what was going on I have taken the liberty of trying to
reword your commit message for English grammar.
Can you pleas
On Wed, Jan 30, 2019 at 09:15:58AM +0100, Juergen Gross wrote:
> On 29/01/2019 18:08, osstest service owner wrote:
> > flight 132544 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/132544/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
Ater some years. I am figure out that on these machime was hardware deffect.
Hardware is not stable.
>
>
>"IRQ problem dom0 xen4.5-amd64"
>i have mothrboard geforce 6100pm-m2(v3.0) latest bios and athtlon 64 x2 5000+
>cpu
>Mothrboard based on nforce 430 chipset
>if in bios enabled apic mode. Xe
On Tue, Jan 29, 2019 at 05:46:55PM +, osstest service owner wrote:
> flight 132468 linux-4.19 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/132468/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-am
Xen will warn when an unknown parameter is found in the command line. e.g.
(d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
One case where this goes wrong is a workaround for an old grub bug, which
resulted in "placeholder" being prepended to the command line.
Another case is when booti
On Wed, Jan 30, 2019 at 03:09:45PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH for-4.12] libxl: When restricted, start QEMU
> paused"):
> > [stuff]
>
> Thanks for this. I think the code looks right but to make it easier
> to understand what was going on I have taken the liberty of
Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.
Signed-off-by: Paul Durrant
---
Cc: Stefan Hajnoczi
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Kevin Wolf
Cc: Max Reitz
v2:
-
Anthony PERARD writes ("Re: [PATCH for-4.12] libxl: When restricted, start QEMU
paused"):
> On Wed, Jan 30, 2019 at 03:09:45PM +, Ian Jackson wrote:
> > - libxl connects and hand-checks [xxx???] with QEMU, then sends the
> > cmd "query-status".
> > - QEMU prepares and maybe tries to se
>>> On 24.01.19 at 11:54, wrote:
On 16.01.19 at 12:40, wrote:
>> On 14/01/2019 12:40, Jan Beulich wrote:
>>> For VPSADBW this likely was a result of bad copy-and-paste.
>>>
>>> For VPS{L,R}LDQ comment and code were not in line, but then again the
>>> comment also wasn't fully updated from t
On 30/01/2019 16:55, Andrew Cooper wrote:
> Xen will warn when an unknown parameter is found in the command line. e.g.
>
> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>
> One case where this goes wrong is a workaround for an old grub bug, which
> resulted in "placeholder" being prep
>>> On 30.01.19 at 16:55, wrote:
> Xen will warn when an unknown parameter is found in the command line. e.g.
>
> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>
> One case where this goes wrong is a workaround for an old grub bug, which
> resulted in "placeholder" being prepended to
flight 132577 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 132485
Te
On 30/01/2019 16:31, Juergen Gross wrote:
> On 30/01/2019 16:55, Andrew Cooper wrote:
>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>
>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>
>> One case where this goes wrong is a workaround for an old grub bu
On 30/01/2019 17:07, Andrew Cooper wrote:
> On 30/01/2019 16:31, Juergen Gross wrote:
>> On 30/01/2019 16:55, Andrew Cooper wrote:
>>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>>
>>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>>
>>> One case where
On 30/01/2019 16:38, Jan Beulich wrote:
On 30.01.19 at 16:55, wrote:
>> Xen will warn when an unknown parameter is found in the command line. e.g.
>>
>> (d8) [ 1556.334664] (XEN) parameter "pv-shim" unknown!
>>
>> One case where this goes wrong is a workaround for an old grub bug, which
>>
flight 132627 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132627/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 21/11/2018 13:21, Andrew Cooper wrote:
> This covers various fixes related to XSA-277 which weren't in security
> supported areas, and associated cleanup.
>
> The biggest issue noticed here is that altp2m's use of hardware #VE support
> will cause general memory corruption if the guest ever ball
On Wed, Jan 30, 2019 at 05:16:47PM +, Andrew Cooper wrote:
> On 30/01/2019 17:07, Andrew Cooper wrote:
> > On 30/01/2019 16:31, Juergen Gross wrote:
> >> On 30/01/2019 16:55, Andrew Cooper wrote:
> >>> Xen will warn when an unknown parameter is found in the command line.
> >>> e.g.
> >>>
> >>
Hi,
On Tue, Jan 01, 2019 at 07:46:57PM +, Andy Smith wrote:
> The test host is slightly different hardware to the others: Xeon
> E5-1680v4 on there as opposed to Xeon D-1540 previously.
>
> Test host is now running with pcid=0 to see if that helps. The
> longest this guest has been able to ru
On 14/01/2019 11:40, Jan Beulich wrote:
> For VPSADBW this likely was a result of bad copy-and-paste.
>
> For VPS{L,R}LDQ comment and code were not in line, but then again the
> comment also wasn't fully updated from the AVX2 original it got cloned
> from.
>
> Signed-off-by: Jan Beulich
I'm guess
Hi Andrew,
On 11/22/18 5:56 PM, Andrew Cooper wrote:
On 21/11/2018 13:21, Andrew Cooper wrote:
* Use XFREE() when appropriate
* Drop stale comments and unnecessary brackets
* Fold asm constraints
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: R
On 30/01/2019 20:04, Julien Grall wrote:
> Hi Andrew,
>
> On 11/22/18 5:56 PM, Andrew Cooper wrote:
>> On 21/11/2018 13:21, Andrew Cooper wrote:
>>> * Use XFREE() when appropriate
>>> * Drop stale comments and unnecessary brackets
>>> * Fold asm constraints
>>>
>>> No functional change.
>>>
>
flight 132633 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132633/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 14/01/2019 12:48, Jan Beulich wrote:
On 14.01.19 at 13:00, wrote:
>> On 14/01/2019 11:39, Jan Beulich wrote:
>>> First of all a PCLMULQDQ dependency was missing entirely. Add it as well
>>> as AESNI and SHA to SSE2, as all of them act on vectors of integers,
>>> whereas plain SSE supports
Dear Community Members,
starting today, registration officially opens for The Xen Project Developer &
Design Summit. This year’s Summit, taking place from July 9 through 11 in
Chicago, will bring together the Xen Project community of developers and power
users to share ideas, latest development
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-xsm
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
T
flight 132578 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129313
test-amd64-
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_ran
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_insert_ran
1 - 100 of 138 matches
Mail list logo
