>>> 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,
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"
>
>
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
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:
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
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
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
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
---
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
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
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
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
>>> 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
>>> 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
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))
>>>
>>>
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;
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
>>> 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
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
>>> 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
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:
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
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
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
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:
>
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
101 - 127 of 127 matches
Mail list logo
