> 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
>>
在 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
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
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
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
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
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
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
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 +
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
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
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
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
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
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
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:
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
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
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
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:
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
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 --
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 ++-
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)[]
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 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
>
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
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
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
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
>>> 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 +=
>>> 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);
> -
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
>>> 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
>
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 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 +-
>>
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 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 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:
> {
>
>>> 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
>>> 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
>>> 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
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
>>> 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,
>
>>> 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.
>
>
>>> 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:
> 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:
> 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:
> 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
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
>>> 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
>>> 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
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
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. >
>>> 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
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 |
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
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
>>
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: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
>>> 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
>>> 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
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 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,
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
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
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
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
>>> 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
>>> 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 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
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
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 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,
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
> >> >
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
>>> 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:
>> >
>> >
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 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
>>> 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 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
>>> 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
>
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 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;
> >
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 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
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
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
>>> 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
>>> +++
>>> 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 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
>>> 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
在 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 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++ )
>> {
>> -
>>> 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
>
>>> 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
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
>>> 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
>>> 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
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)
-
1 - 100 of 103 matches
Mail list logo
