Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
On 2018/08/24 22:52, Michal Hocko wrote:
@@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*/
static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable)
{
- if (blockable)
- mutex_lock(&amn->read_l
>>> On 26.08.18 at 13:04, wrote:
> On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
>>
>> > --- a/xen/arch/x86/mm/shadow/multi.c
>> > +++ b/xen/arch/x86/mm/shadow/multi.c
>> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
>> > }
>> > else
>
>>> On 24.08.18 at 10:58, wrote:
> On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote:
>> What could be causing the long startup time of qemu on these hosts? Does
>> dom0 have enough cpu/memory? As you noticed, the libvirt commit used for
>> this test has not changed in a long time, well b
Marc-André Lureau writes:
> Hi
> On Fri, Aug 24, 2018 at 9:37 AM Markus Armbruster wrote:
>>
>> Marc-André Lureau writes:
>>
>> > This is mostly for readability of the code. Let's make it clear which
>> > callers can create an implicit monitor when the chardev is muxed.
>> >
>> > This will also
>>> On 22.08.18 at 11:16, wrote:
> Given what pt_pci_init() actually does, rename it properly and move its
> declaration to pci.h, move the only call in acpi_mmcfg_init().
>
> No functional change.
>
> Signed-off-by: Zhenzhong Duan
> Tested-by: Gopalasetty, Manoj
> Acked-by: Jan Beulich
Plea
>>> On 24.08.18 at 04:56, wrote:
> When trying to build both xen and qemu-xen from the staging-4.9
> branches, I'm running into issues compiling.
>
> Errors start with:
>
> BUILDSTDERR: sse.c: In function 'simd_test':
> BUILDSTDERR: sse.c:319: error: subscripted value is neither array nor
> po
>>> On 22.08.18 at 16:28, wrote:
> On Wed, Aug 22, 2018 at 05:02:41PM +0300, Alexandru Isaila wrote:
>> @@ -223,17 +222,37 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h)
>> /* Save all available kinds of state */
>> for ( i = 0; i <= HVM_SAVE_CODE_MAX; i++ )
>> {
>> -
在 2018/8/27 16:16, Jan Beulich 写道:
On 22.08.18 at 11:16, wrote:
Given what pt_pci_init() actually does, rename it properly and move its
declaration to pci.h, move the only call in acpi_mmcfg_init().
No functional change.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
Acked-by:
>>> On 27.08.18 at 08:43, wrote:
> Since about two weeks, no released qemu can be built against xen.git#staging.
> The error looks like that:
>
> qemu-20180825T130857.235c82acca/include/hw/xen/xen_common.h:677:5: error: too
> many arguments to function 'xc_domain_create'
>
> It looks like stag
On Sun, Aug 26, 2018 at 01:19:48PM +0100, Wei Liu wrote:
> Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
> Put these components under CONFIG_HVM. This further requires putting
> one of the vm event under CONFIG_HVM.
>
> Also make hap_enabled evaluate to false when !CONFIG_HV
>>> On 24.08.18 at 14:16, wrote:
> Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
> for unimplemented IOCTLs") will return -EINVAL rather than the conventional
> -ENOTTY for unimplemented codes. This breaks the error path in
> libxenforeignmemory resource mapping, which on
>>> On 24.08.18 at 20:47, wrote:
> On 8/24/18 8:49 PM, Andrew Cooper wrote:
>> On 24/08/18 15:11, Alexandru Isaila wrote:
>>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>>> index 03a864156..b01194d 100644
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/m
On Mon, Aug 27, 2018 at 03:04:55AM -0600, Jan Beulich wrote:
> >>> On 24.08.18 at 14:16, wrote:
> > Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
> > for unimplemented IOCTLs") will return -EINVAL rather than the conventional
> > -ENOTTY for unimplemented codes. This brea
On Mon, Aug 27, 2018 at 01:46:10AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 13:04, wrote:
> > On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
> >>
> >> > --- a/xen/arch/x86/mm/shadow/multi.c
> >> > +++ b/xen/arch/x86/mm/shadow/multi.c
> >> > @@ -2926,18 +2926,25 @@ static int s
>>> On 22.08.18 at 09:51, wrote:
> Hello,
>
> The following series implement a workaround for missing RMRR
> entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
> option.
>
> The PVH workaround identity maps all regions marked as reserved in the
> memory map.
>
> Note that thi
On Tue, Jul 31, 2018 at 05:37:30AM -0600, Jan Beulich wrote:
> >>> On 25.07.18 at 13:16, wrote:
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -234,7 +234,7 @@ struct xen_hvm_altp2m_view {
> > typedef struct xen_hvm_altp2m_view xen_hvm_altp2m_view_t;
>
On Tue, Jul 31, 2018 at 05:44:03AM -0600, Jan Beulich wrote:
> >>> On 25.07.18 at 13:18, wrote:
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -38,7 +38,7 @@ struct xen_hvm_param {
> > typedef struct xen_hvm_param xen_hvm_param_t;
> > DEFINE_XEN_GUEST_
On Tue, Jul 31, 2018 at 05:53:00AM -0600, Jan Beulich wrote:
> > +struct vcpu *v;
> > +
> > +dom = rcu_lock_domain_by_id(domain_id);
> > +
> > +for_each_vcpu( dom, v )
> > +{
> > +if ( vcpu_id == v->vcpu_id )
> > +{
> > +rcu_unlock_domain(dom);
> > +
>>> On 22.08.18 at 12:36, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/configs/pvshim_defconfig
> @@ -0,0 +1,23 @@
> +# Enable PV shim mode
> +CONFIG_PV=y
> +CONFIG_XEN_GUEST=y
> +CONFIG_PVH_GUEST=y
> +CONFIG_PV_SHIM=y
> +CONFIG_PV_SHIM_EXCLUSIVE=y
> +# Disable features not used by the PV shim
> +C
>>> On 24.08.18 at 11:58, wrote:
> --- /dev/null
> +++ b/tools/firmware/hvmloader/hvmloader.lds
> @@ -0,0 +1,13 @@
> +SECTIONS
> +{
> + . = 0x10;
> + /*
> + * NB: there's no need to use the AT keyword in order to set the LMA, by
> + * default the linker will use VMA = LMA unless specifie
>>> On 24.08.18 at 17:22, wrote:
> Building rombios with clang XXX fails with:
>
> tcgbios.c:1519:34: error: taking address of packed member 'u' of class or
> structure 'pushad_regs_t' may result in an unaligned pointer value
> [-Werror,-Waddress-of-packed-member]
>
>>> On 27.08.18 at 11:38, wrote:
> On Tue, Jul 31, 2018 at 05:37:30AM -0600, Jan Beulich wrote:
>> >>> On 25.07.18 at 13:16, wrote:
>> > --- a/xen/include/public/hvm/hvm_op.h
>> > +++ b/xen/include/public/hvm/hvm_op.h
>> > @@ -234,7 +234,7 @@ struct xen_hvm_altp2m_view {
>> > typedef struct xen_
On Monday, 27 August 2018 6:32:17 PM AEST Jan Beulich wrote:
> >>> On 24.08.18 at 04:56, wrote:
> > When trying to build both xen and qemu-xen from the staging-4.9
> > branches, I'm running into issues compiling.
> >
> > Errors start with:
> >
> > BUILDSTDERR: sse.c: In function 'simd_test':
> >
>>> On 27.08.18 at 12:03, wrote:
> On Monday, 27 August 2018 6:32:17 PM AEST Jan Beulich wrote:
>> >>> On 24.08.18 at 04:56, wrote:
>> > When trying to build both xen and qemu-xen from the staging-4.9
>> > branches, I'm running into issues compiling.
>> >
>> > Errors start with:
>> >
>> > BUILD
flight 126677 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125183
test-amd64-amd64-pair
On Mon, Aug 27, 2018 at 03:59:16AM -0600, Jan Beulich wrote:
> >>> On 27.08.18 at 11:38, wrote:
> > On Tue, Jul 31, 2018 at 05:37:30AM -0600, Jan Beulich wrote:
> >> >>> On 25.07.18 at 13:16, wrote:
> >> > --- a/xen/include/public/hvm/hvm_op.h
> >> > +++ b/xen/include/public/hvm/hvm_op.h
> >> > @
On 8/27/18 12:11 PM, Jan Beulich wrote:
On 24.08.18 at 20:47, wrote:
>> 619 /* EPT violation qualifications definitions */
>> 620 typedef union ept_qual {
>> 621 unsigned long raw;
>> 622 struct {
>> 623 bool read:1, write:1, fetch:1,
>> 624 eff_read:1, eff_write:1
flight 126763 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 126702
build-armhf
On Monday, 27 August 2018 8:36:50 PM AEST Jan Beulich wrote:
> >>> On 27.08.18 at 12:03, wrote:
> > On Monday, 27 August 2018 6:32:17 PM AEST Jan Beulich wrote:
> >> >>> On 24.08.18 at 04:56, wrote:
> >> > When trying to build both xen and qemu-xen from the staging-4.9
> >> > branches, I'm runnin
On Sat, Aug 25, 2018 at 1:21 AM Juergen Gross wrote:
>
> On 24/08/18 20:43, Jason Andryuk wrote:
> > On Wed, Aug 15, 2018 at 10:39 AM Juergen Gross wrote:
> >>
> >> On 15/08/18 16:10, Jan Beulich wrote:
> >> On 15.08.18 at 15:17, wrote:
> 2) 32bit PV guests which use writeable pagetable
>>> On 27.08.18 at 13:24, wrote:
> On 8/27/18 12:11 PM, Jan Beulich wrote:
> On 24.08.18 at 20:47, wrote:
>>> 619 /* EPT violation qualifications definitions */
>>> 620 typedef union ept_qual {
>>> 621 unsigned long raw;
>>> 622 struct {
>>> 623 bool read:1, write:1, fetch:1,
>>> On 27.08.18 at 13:30, wrote:
> On Monday, 27 August 2018 8:36:50 PM AEST Jan Beulich wrote:
>> >>> On 27.08.18 at 12:03, wrote:
>> > On Monday, 27 August 2018 6:32:17 PM AEST Jan Beulich wrote:
>> >> >>> On 24.08.18 at 04:56, wrote:
>> >> > When trying to build both xen and qemu-xen from the
On 8/27/18 3:12 PM, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request was a user or "system" one? If not, some cheating
>>> would be needed (derive from CPL, accepting that e.g.
>>> descriptor table accesses would get mis-attributed), but
>>> that's s
On 27/08/18 13:12, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request was a user or "system" one? If not, some cheating
>>> would be needed (derive from CPL, accepting that e.g.
>>> descriptor table accesses would get mis-attributed), but
>>> that's st
flight 126742 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126742/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 983f5abb9a0d6cf9cfb5e16d671f15e5dc7510d8
baseline version:
ovmf 6861765935d5b69803321
On 8/27/18 3:37 PM, Andrew Cooper wrote:
> On 27/08/18 13:12, Jan Beulich wrote:
For NPT, isn't there an error code bit telling you whether the
request was a user or "system" one? If not, some cheating
would be needed (derive from CPL, accepting that e.g.
descriptor table access
On 27/08/18 13:53, Razvan Cojocaru wrote:
> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>> On 27/08/18 13:12, Jan Beulich wrote:
> For NPT, isn't there an error code bit telling you whether the
> request was a user or "system" one? If not, some cheating
> would be needed (derive from CPL,
flight 126771 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126771/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 126702
build-armhf
>>> On 27.08.18 at 15:02, wrote:
> On 27/08/18 13:53, Razvan Cojocaru wrote:
>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>>> On 27/08/18 13:12, Jan Beulich wrote:
>> For NPT, isn't there an error code bit telling you whether the
>> request was a user or "system" one? If not, some cheating
>>> On 07.08.18 at 17:42, wrote:
> My recent patch [1] to qemu-xen-traditional removes the last use of the
> 'default' ioreq server in Xen. (This is a catch-all ioreq server that is
> used if no explicitly registered I/O range is targetted).
>
> This patch can be applied once that patch is commit
On 8/27/18 4:02 PM, Andrew Cooper wrote:
> On 27/08/18 13:53, Razvan Cojocaru wrote:
>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
>>> On 27/08/18 13:12, Jan Beulich wrote:
>> For NPT, isn't there an error code bit telling you whether the
>> request was a user or "system" one? If not, some ch
On 08/26/2018 08:19 AM, Wei Liu wrote:
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
>
> Requested-by: Andrew Cooper
AMD SDM doesn't make distinction between linear and virtual addresses so
I wonder why this was requested.
-boris
On 8/27/18 4:17 PM, Jan Beulich wrote:
On 27.08.18 at 15:02, wrote:
>> This should be architecturally correct as it is exclusively derived from
>> information provided by the VMExit, and won't cause dirty bits to be
>> written in cases where the hardware wouldn't have written them
>> (specula
flight 126683 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126683/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail
in 126564 pass in 126683
test-a
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile| 1 -
xen/arch/arm/platforms/exynos5.c | 3
>>> On 27.08.18 at 15:49, wrote:
> On 08/26/2018 08:19 AM, Wei Liu wrote:
>> They all incorrectly named a parameter virtual address while it should
>> have been linear address.
>>
>> Requested-by: Andrew Cooper
>
> AMD SDM doesn't make distinction between linear and virtual addresses so
> I wond
Hi Julien, Marc
On 24.08.18 19:58, Julien Grall wrote:
From: Marc Zyngier
An unfortunate consequence of having a strong typing for the input
values to the SMC call is that it also affects the type of the
return values, limiting r0 to 32 bits and r{1,2,3} to whatever
was passed as an input. >
Hi,
On 24.08.18 19:58, Julien Grall wrote:
From: Marc Zyngier
If someone has the silly idea to write something along those lines:
extern u64 foo(void);
void bar(struct arm_smccc_res *res)
{
arm_smccc_1_1_smc(0xbad, foo(), res);
}
they are in f
>>> On 27.08.18 at 15:24, wrote:
> On 8/27/18 4:02 PM, Andrew Cooper wrote:
>> On 27/08/18 13:53, Razvan Cojocaru wrote:
>>> On 8/27/18 3:37 PM, Andrew Cooper wrote:
On 27/08/18 13:12, Jan Beulich wrote:
>>> For NPT, isn't there an error code bit telling you whether the
>>> request wa
>>> On 27.08.18 at 15:47, wrote:
> On 8/27/18 4:17 PM, Jan Beulich wrote:
> On 27.08.18 at 15:02, wrote:
>>> This should be architecturally correct as it is exclusively derived from
>>> information provided by the VMExit, and won't cause dirty bits to be
>>> written in cases where the hardwar
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 8
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/
>>> On 26.08.18 at 14:19, wrote:
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-de
>>> On 26.08.18 at 14:19, wrote:
> PV guest (Dom0) needs to able to use these two hypercalls in order to
> serve HVM guests. But if xen doesn't support HVM at all there is no
> point in exposing them to PV guests.
>
> Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
_
>>> On 26.08.18 at 14:19, wrote:
> Turn them into static inline functions which evaluate to false when
> CONFIG_HVM is not set. ARM won't be broken because ARM guests are set
> to PV type in the hypervisor.
>
> But ARM has plan to switch to HVM guest type inside the hypervisor, so
> preemptively
>>> On 26.08.18 at 14:19, wrote:
> And replace direct accesses in non-HVM subsystems to
> hvm_funcs.hap_supported with the new function, to avoid accessing an
> internal data structure of another subsystem directly.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
__
>>> On 26.08.18 at 14:19, wrote:
> Jan indicated that for PV guests the memory type is not changed, for
> HVM guests memory_type_changed is needed for EPT's effective memory
> type calculation. This means memory_type_changed is HVM only.
>
> Provide a stub to minimise code churn.
>
> Signed-off
>>> On 26.08.18 at 14:19, wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
>
> ret = pci_mmcfg_reserved(info.address, info.segment,
> info.start_
flight 126682 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125898
test-amd64-i386-fre
>>> On 26.08.18 at 14:19, wrote:
> Change u32 to uint32_t while at it.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 26.08.18 at 14:19, wrote:
> We also need to make it x86 only because ARM also defines CONFIG_HVM.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailma
>>> On 26.08.18 at 14:19, wrote:
> This requires providing stubs for a few functions which are part of
> HVM code.
>
> Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
>>> On 26.08.18 at 14:19, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4376,12 +4376,17 @@ int arch_acquire_resource(struct domain *d, unsigned
> int type,
>
> switch ( type )
> {
> +#ifdef CONFIG_HVM
> case XENMEM_resource_ioreq_server:
> {
> io
>>> On 26.08.18 at 14:19, wrote:
> There has been plan to make PV work, but it is not yet there. Provide
> stubs to make it build with !CONFIG_HVM.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/Makefile | 2 +-
> xen/include/asm-x86/monitor.h | 14 ++
> 2 files changed,
On 27/08/2018 15:03, Volodymyr Babchuk wrote:
Hi Julien, Marc
Hi,
On 24.08.18 19:58, Julien Grall wrote:
From: Marc Zyngier
An unfortunate consequence of having a strong typing for the input
values to the SMC call is that it also affects the type of the
return values, limiting r0 to 32
On 8/27/18 6:18 PM, Jan Beulich wrote:
On 26.08.18 at 14:19, wrote:
>> There has been plan to make PV work, but it is not yet there. Provide
>> stubs to make it build with !CONFIG_HVM.
>>
>> Signed-off-by: Wei Liu
>> ---
>> xen/arch/x86/Makefile | 2 +-
>> xen/include/asm-x86/moni
On 27/08/2018 15:15, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 24.08.18 19:58, Julien Grall wrote:
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 8
3 files changed, 14
>>> On 26.08.18 at 14:19, wrote:
> Make sure hvm_enabled evaluate to false then provide necessary stubs,
> declarations and macros to make Xen build.
>
> The is_viridian_domain macro can't be turned into an inline function
> easily, so instead its caller is modified to avoid unused variable
> war
flight 126779 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126779/
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 26.08.18 at 14:19, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1689,7 +1689,8 @@ void context_switch(struct vcpu *prev, struct vcpu
> *next)
> {
> _update_runstate_area(prev);
> vpmu_switch_from(prev);
> -np2m_schedule(NP2M_SCHEDL
>>> On 26.08.18 at 14:19, wrote:
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -1,9 +1,10 @@
> subdir-y += shadow
> -subdir-y += hap
> +subdir-$(CONFIG_HVM) += hap
>
> obj-y += paging.o
> -obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
> -obj-y += altp2m.o
> +obj-y += p2m
On Tue, Aug 21, 2018 at 11:40 AM Juergen Gross wrote:
>
> While the hypervisor emulates plain writes to PTEs happily, this is
> much slower than issuing a hypercall for PTE modifcations. And writing
> a PTE via two 32-bit write instructions (especially when clearing the
> PTE) will result in an in
On Mon, Aug 27, 2018 at 12:03 PM Jason Andryuk wrote:
>
> On Tue, Aug 21, 2018 at 11:40 AM Juergen Gross wrote:
> >
> > While the hypervisor emulates plain writes to PTEs happily, this is
> > much slower than issuing a hypercall for PTE modifcations. And writing
> > a PTE via two 32-bit write ins
On Fri, Aug 24, 2018 at 03:52:23PM +0200, Juergen Gross wrote:
> On 17/08/18 17:59, Roger Pau Monné wrote:
> > On Mon, Aug 13, 2018 at 04:01:09PM +0200, Juergen Gross wrote:
> >> Persistent grants are used in the Xen's blkfront/blkback drivers to
> >> avoid mapping/unmapping of I/O buffers in the b
Hey Jens,
Would you be OK pulling the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.19
which has a fix for flushing out persistent pages at a deterministic rate.
Thanks to the L1TF I did not manage to send this email until today - but
hopefull
On Mon, Aug 20, 2018 at 02:33:10AM -0600, Jan Beulich wrote:
> >>> On 19.08.18 at 04:22, wrote:
> > The tboot targets are woefully out of date. These should really be
> > retired because setting up tboot is more complex than the build process
> > for it.
> >
> > Signed-off-by: Doug Goldstein
>
Julien,
On 27.08.18 18:23, Julien Grall wrote:
On 27/08/2018 15:03, Volodymyr Babchuk wrote:
Hi Julien, Marc
Hi,
On 24.08.18 19:58, Julien Grall wrote:
From: Marc Zyngier
An unfortunate consequence of having a strong typing for the input
values to the SMC call is that it also affects
On Thu, Jul 19, 2018 at 6:39 AM Jason Andryuk wrote:
>
> If panic is called before init_idle_domain on a tboot-launched system,
> then Xen recursively faults in write_ptbase as seen below.
>
> (XEN)[] write_ptbase+0/0x10
> (XEN)[] tboot_shutdown+0x6b/0x260
> (XEN)[] machine_restart+0xa
Hi,
On 27.08.18 18:29, Julien Grall wrote:
On 27/08/2018 15:15, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 24.08.18 19:58, Julien Grall wrote:
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smc
This series of patches is for enabling SSBD via the LS_CFG MSR for
family 15h-17h. The first patch make it so that the information is
correctly displayed on boot. The last patch is for further enablement
for Xen switching SSBD on or off internally, or for further control of
SSBD for guests via th
Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
enable it to pass the status to the initial spec-ctrl print_details at
boot.
Signed-off-by: Brian Woods
---
xen/arch/x86/cpu/amd.c | 12 +---
xen/arch/x86/spec_ctrl.c| 10 --
xen/include/asm-x86/s
Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
AMD CPUs. There needs to be locking logic for family 17h with SMT
enabled since both threads share the same MSR. Otherwise, a core just
needs to write to the LS_CFG MSR. For more information see:
https://developer.amd.com/wp-
On 8/27/18 10:19 AM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
>
> Would you be OK pulling the following branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.19
>
> which has a fix for flushing out persistent pages at a deterministic rate.
>
> Thanks to the
flight 126710 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248
test-amd64-amd6
flight 75129 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75129/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 75096
test-amd64-amd64-i386-sid-netboot-pygru
flight 126761 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126761/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass
version targeted for testing:
fre
flight 126773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126773/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 033949a810cd9cb4a604cf09af503459ea1d66dc
baseline version:
ovmf 983f5abb9a0d6cf9cfb5e
Export device state to sysfs to allow for easier get device state.
Signed-off-by: Joe Jin
Boris Ostrovsky
Juergen Gross
---
drivers/xen/xenbus/xenbus_probe.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
inde
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid guest-start/debian
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-tradition
Hi Julien,
On 22.08.18 20:03, Julien Grall wrote:
[...]
if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
goto fail;
+ /* Notify TEE that new domain was created */
+ tee_domain_create(d);
My concern about domain creation is still not addressed. I would expect
On 08/21/2018 11:37 AM, Juergen Gross wrote:
> While the hypervisor emulates plain writes to PTEs happily, this is
> much slower than issuing a hypercall for PTE modifcations. And writing
> a PTE via two 32-bit write instructions (especially when clearing the
> PTE) will result in an intermediate L
Hi Jan,
On 27.08.18 09:44, Jan Beulich wrote:
[...]
xen/arch/arm/arm32/Makefile | 1 +
xen/arch/arm/arm32/smc.S | 39 +++
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/asm-offsets.c | 4
xen/arch/arm/arm64/smc.S
Hello,
On 27/08/2018 20:24, Volodymyr Babchuk wrote:
>
>
> On 27.08.18 09:44, Jan Beulich wrote:
>
> [...]
>
>>> xen/arch/arm/arm32/Makefile | 1 +
>>> xen/arch/arm/arm32/smc.S | 39
>>> +++
>>> xen/arch/arm/arm64/Makefile | 1 +
>>>
Hi
On Mon, Aug 27, 2018 at 10:10 AM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > Hi
> > On Fri, Aug 24, 2018 at 9:37 AM Markus Armbruster wrote:
> >>
> >> Marc-André Lureau writes:
> >>
> >> > This is mostly for readability of the code. Let's make it clear which
> >> > callers c
This run is configured for baseline tests only.
flight 75128 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75128/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-pvgrub 19 guest-start/debian.repeat fail blocked in 7
flight 126716 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
125057
test-am
flight 126711 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 126042
test-amd64-i386-xl-x
This run is configured for baseline tests only.
flight 75130 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75130/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75123
test
flight 126730 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
在 2018年8月28日，上午12:24，Doug Goldstein 写道：
>
> On Mon, Aug 20, 2018 at 02:33:10AM -0600, Jan Beulich wrote:
> On 19.08.18 at 04:22, wrote:
>>> The tboot targets are woefully out of date. These should really be
>>> retired because setting up tboot is more complex than the build process
>>> for i
> On Aug 28, 2018, at 12:44 AM, Jason Andryuk wrote:
>
>> On Thu, Jul 19, 2018 at 6:39 AM Jason Andryuk wrote:
>>
>> If panic is called before init_idle_domain on a tboot-launched system,
>> then Xen recursively faults in write_ptbase as seen below.
>>
>> (XEN)[] write_ptbase+0/0x10
>> (X
1 - 100 of 103 matches
Mail list logo
