Am Mon, 03 Sep 2018 06:35:42 -0600
schrieb "Jan Beulich" :
> what is the actual problem? The mere
> listing of compiler flags passed does not make clear to me where the clash
> is, or how it would surface.
As I noticed just now, it fails to build only in Tumbleweed. So in this
specific case osst
>>> On 03.09.18 at 18:20, wrote:
> On 27/07/18 15:20, Jan Beulich wrote:
>> In order to mostly eliminate abuse of what Xen leaves in the RSB by
>> guest level attackers, fill the RSB with almost-NULL pointers right
>> before entering guest context.
>
> How do you envisage an attacker using what X
On 03/09/18 15:41, Jan Beulich wrote:
On 31.08.18 at 17:22, wrote:
>> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>> filled rather weird: the size of the array is derived from the highest
>> online cpu number, so in case there are trailing offline cpus they
>> will not b
>>> On 03.09.18 at 18:15, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 03 September 2018 16:45
>>[...]
>> The extra call to known_glfn() from hvmemul_write() is just to preserve
>> original behavior; we should consider dropping this (also to make sure
>> the intended effect of 8
>>> On 03.09.18 at 18:43, wrote:
> On 29/08/18 15:23, Jan Beulich wrote:
>> FMA insns, other than the earlier AVX additions, don't use the low
>> opcode bit to distinguish between single and double vector elements.
>
> I think I've worked out why "other than the" is so weird to read as a
> native
flight 127247 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127247/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
>>> On 03.09.18 at 19:57, wrote:
> On 29/08/18 15:24, Jan Beulich wrote:
>> These are all VEX encoded, so the EVEX decoding logic continues to
>> remain unused at this point.
>>
>> The new testcase is deliberately coded in assembly, as a C one would
>> have become almost unreadable due to the over
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 September 2018 08:44
> To: Paul Durrant
> Cc: Olaf Hering ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH v2 2/2] x86/HVM: split page straddling emulated
> accesses in more cases
Or else it defaults to using 0x10 as the entry point, which might
or might not point to _start. This is a fix for 09b3907f93.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Ian Jackson
---
tools/firmware/hvmloader/hvmloade
>>> On 04.09.18 at 08:48, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 3, 2018 7:47 PM
>>
>> >>> On 03.09.18 at 10:23, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 30 August 2018 17:00
>> >>
>> >> >>> On 23.08.18 at 11:46, wrote:
>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 4, 2018 4:33 PM
> >
> > bus address is commonly used along with physical/virtual address, to
> > represent different views between devices and CPU. From that angle
> > I think BFN is a clear term in this context. btw it is no
flight 127243 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
On Tue, Sep 04, 2018 at 10:28:43AM +0200, Roger Pau Monne wrote:
> Or else it defaults to using 0x10 as the entry point, which might
> or might not point to _start. This is a fix for 09b3907f93.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
Ooops, missed that.
Reviewed-by
On Tue, Sep 04, 2018 at 07:55:04AM +, osstest service owner wrote:
> flight 127247 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/127247/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-
>>> On 04.09.18 at 10:15, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 04 September 2018 08:44
>>
>> >>> On 03.09.18 at 18:15, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 03 September 2018 16:45
>> >>[...]
>> >> The extra call to known_glfn() from hvm
On Tue, Sep 04, 2018 at 09:45:53AM +0100, Wei Liu wrote:
> On Tue, Sep 04, 2018 at 07:55:04AM +, osstest service owner wrote:
> > flight 127247 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/127247/
> >
> > Regressions :-(
> >
> > Tests which did not succe
>>> On 04.09.18 at 10:37, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, September 4, 2018 4:33 PM
>> >
>> > bus address is commonly used along with physical/virtual address, to
>> > represent different views between devices and CPU. From that angle
>> > I think BFN is a
>>> On 04.09.18 at 09:38, wrote:
> On 03/09/18 15:41, Jan Beulich wrote:
> On 31.08.18 at 17:22, wrote:
>>> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>>> filled rather weird: the size of the array is derived from the highest
>>> online cpu number, so in case there are
On 04/09/18 09:45, Wei Liu wrote:
> On Tue, Sep 04, 2018 at 07:55:04AM +, osstest service owner wrote:
>> flight 127247 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/127247/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> includi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 September 2018 09:47
> To: Kevin Tian
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Paul Durrant ; Stefano
> Stabellini ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH v6 01/14] iommu
On Tue, Sep 04, 2018 at 09:49:11AM +0100, Andrew Cooper wrote:
> On 04/09/18 09:45, Wei Liu wrote:
> > On Tue, Sep 04, 2018 at 07:55:04AM +, osstest service owner wrote:
> >> flight 127247 xen-unstable-smoke real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/127247/
> >>
> >> Reg
On 04/09/18 09:53, Wei Liu wrote:
> On Tue, Sep 04, 2018 at 09:49:11AM +0100, Andrew Cooper wrote:
>> On 04/09/18 09:45, Wei Liu wrote:
>>> On Tue, Sep 04, 2018 at 07:55:04AM +, osstest service owner wrote:
flight 127247 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.o
>>> On 04.09.18 at 09:32, wrote:
> Am Mon, 03 Sep 2018 06:35:42 -0600
> schrieb "Jan Beulich" :
>
>> what is the actual problem? The mere
>> listing of compiler flags passed does not make clear to me where the clash
>> is, or how it would surface.
>
> As I noticed just now, it fails to build onl
>>> On 04.09.18 at 10:49, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 04 September 2018 09:47
>> To: Kevin Tian
>> Cc: Suravee Suthikulpanit ; Julien Grall
>> ; Paul Durrant ; Stefano
>> Stabellini ; xen-devel > de...@lists.xenproject.org>
>> Sub
flight 127221 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127221/
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 10 debian-hvm-install
fail REGR. vs. 125898
Hi,
On 09/04/2018 09:49 AM, Jan Beulich wrote:
On 04.09.18 at 09:38, wrote:
On 03/09/18 15:41, Jan Beulich wrote:
On 31.08.18 at 17:22, wrote:
The topology information obtainable via XEN_SYSCTL_cputopoinfo is
filled rather weird: the size of the array is derived from the highest
online cpu
The generated header files are what needs to spell out dependencies on
other (real) headers in the main Makefile here, not the intermediate
(helper) .o files produced through testcase.mk.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@
>>> On 03.09.18 at 17:43, wrote:
> It can easily be expressed through hvm_copy_from_guest_linear(), and in
> two cases this even simplifies callers.
>
> Suggested-by: Paul Durrant
> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
> ---
> v2: Make sure this compiles standalone. Slightly
On 04/09/18 10:58, Jan Beulich wrote:
> The generated header files are what needs to spell out dependencies on
> other (real) headers in the main Makefile here, not the intermediate
> (helper) .o files produced through testcase.mk.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
>>> On 03.09.18 at 18:46, 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 23.08.18 at 11:46, wrote:
> This patch modifies the declaration of the entry points to the IOMMU
> sub-system to use bfn_t and mfn_t in place of unsigned long. A subsequent
> patch will similarly modify the methods in the iommu_ops structure.
>
> Signed-off-by: Paul Durrant
> Reviewed-by:
>>> On 23.08.18 at 11:47, wrote:
> This patch modifies the methods in struct iommu_ops to use type-safe BFN
> and MFN. This follows on from the prior patch that modified the functions
> exported in xen/iommu.h.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Wei Liu
> Reviewed-by: Kevin Tian
A
>>> On 23.08.18 at 11:47, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1154,6 +1154,7 @@ map_grant_ref(
> }
> if ( err )
> {
> +domu_crash(ld);
> double_gt_unlock(lgt, rgt);
You crash the domain with both locks
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 September 2018 11:38
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Jun Nakajima ; Kevin Tian
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
flight 127252 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests
On 29/08/18 15:25, Jan Beulich wrote:
> Fix an inverted pair of checks, drop an incorrect instance of #UD
> raising for non-64-bit mode, and add further generic checks.
>
> Note: Other than SDM Vol 2 rev 067 states, EVEX.V' is _not_ ignored
> outside of 64-bit mode when the field does not enc
On 29/08/18 15:25, Jan Beulich wrote:
> @@ -2818,6 +2818,9 @@ x86_decode(
>
> opcode |= b | MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
>
> +if ( !evex.mbs )
This use of mbs is very confusing to read. How about:
#define evex_encoded evex.mbs
which at least giv
On 09/03/2018 07:37 PM, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Julien Grall [mailto:julien.gr...@arm.com]
>> Sent: 03 September 2018 18:14
>> To: Shameerali Kolothum Thodi ;
>> xen-de...@lists.xen.org
>> Cc: sstabell...@kernel.org; Linuxarm ; Andre
>> Przywa
'xl sysrq' command doesn't work with modern Linux guests with the following
message in guest's log:
xen:manage: sysrq_handler: Error -13 writing sysrq in control/sysrq
xenstore trace confirms:
IN 0x24bd9a0 20180904 04:36:32 WRITE (control/sysrq )
OUT 0x24bd9a0 20180904 04
>>> On 23.08.18 at 11:47, wrote:
> --- /dev/null
> +++ b/xen/common/iommu_op.c
> @@ -0,0 +1,184 @@
> +/**
> + * x86/iommu_op.c
Oops?
> +int do_one_iommu_op(xen_iommu_op_buf_t *buf)
> +{
> +xen_iommu_op_t op;
> +i
On 03/09/18 17:03, Jan Beulich wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -272,8 +272,12 @@ struct domain *domain_create(domid_t domid,
>> if ( (d = alloc_domain_struct()) == NULL )
>> return ERR_PTR(-ENOMEM);
>>
>> +/* Sort out our idea of is_system_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 September 2018 12:50
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>
> Subject: Re: [PATCH v6 05
>>> On 04.09.18 at 12:48, wrote:
> On 29/08/18 15:25, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -650,7 +650,7 @@ union evex {
>> uint8_t w:1;
>> uint8_t opmsk:3;
>> uint8_t RX:1;
>> -u
>>> On 04.09.18 at 13:02, wrote:
> On 29/08/18 15:25, Jan Beulich wrote:
>> @@ -2818,6 +2818,9 @@ x86_decode(
>>
>> opcode |= b | MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
>>
>> +if ( !evex.mbs )
>
> This use of mbs is very confusing to read. How about:
>
>
>>> On 04.09.18 at 14:17, wrote:
> On 03/09/18 17:03, Jan Beulich wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -272,8 +272,12 @@ struct domain *domain_create(domid_t domid,
>>> if ( (d = alloc_domain_struct()) == NULL )
>>> return ERR_PTR(-ENOMEM);
>>>
On Mon, Apr 23, 2018 at 4:17 AM Juergen Gross wrote:
> On 20/04/18 17:20, Jason Andryuk wrote:
> > Adding xen-devel and the Linux Xen maintainers.
> >
> > Summary: Some Xen users (and maybe others) are hitting a BUG in
> > __radix_tree_lookup() under do_swap_page() - example backtrace is
> > provi
>>> On 04.09.18 at 14:23, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 04 September 2018 12:50
>>
>> >>> On 23.08.18 at 11:47, wrote:
>> > +int compat_one_iommu_op(compat_iommu_op_buf_t *buf)
>> > +{
>> > +compat_iommu_op_t cmp;
>> > +xen_iommu_op_t nat;
>> > +int
flight 127260 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127260/
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
This run is configured for baseline tests only.
flight 75162 seabios real [real]
http://osstest.xensource.com/osstest/logs/75162/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 75114
t
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 September 2018 13:55
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: RE: [PATCH v6 05/
On 09/03/2018 09:46 AM, Wei Liu wrote:
On Sun, Aug 26, 2018 at 01:19:34PM +0100, Wei Liu 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
Is there more comment on this?
These being ra
flight 127232 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127232/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 126854
test-armhf-armhf-libvirt 14 save
This run is configured for baseline tests only.
flight 75163 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75163/
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 75160
test
flight 127265 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127265/
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
Fixes: f030aade9165 ("x86/xen: Move pv specific parts of arch/x86/xen/mmu.c to
mmu_pv.c")
Signed-off-by: kbuild test robot
---
mmu_pv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index bf30fa0..7ada9e4 100644
--- a/arch/x
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/paravirt
head: 495310e4f2dd857c4d5a62806a04cb8ba53855c1
commit: f030aade9165080f3539fb86fc2ce9ffc391813c [2/15] x86/xen: Move pv
specific parts of arch/x86/xen/mmu.c to mmu_pv.c
reproduce:
# apt-get install sparse
flight 75164 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start fail REGR. vs. 75133
Tests which did
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 04 September 2018 12:22
> To: Shameerali Kolothum Thodi ;
> xen-de...@lists.xen.org
> Cc: sstabell...@kernel.org; Linuxarm ; Andre
> Przywara
> Subject: Re: Xen Dom0 boot failure on platform that supports ARM
On 16/08/18 13:27, Jan Beulich wrote:
On 16.08.18 at 12:56, wrote:
>> On 16/08/18 11:29, Jan Beulich wrote:
>>> Following some further discussion with Andrew, he looks to be
>>> convinced that the issue is to be fixed in the balloon driver,
>>> which so far (intentionally afaict) does not rem
Move the file to x86 common code and change its name to emul-i8254.c.
Put HVM only code under CONFIG_HVM or is_hvm_domain.
Signed-off-by: Wei Liu
---
v3: remove some CONFIG_HVMs, rely on DCE
v2: move the whole file.
---
xen/arch/x86/Makefile | 1 +
xen/arch/x86/{hvm/i8254.
Populate-on-demand is HVM only.
Provide a bunch of stubs for common p2m code and guard one invocation
of guest_physmap_mark_populate_on_demand with is_hvm_domain.
Put relevant fields in p2m_domain and code which touches those fields
under CONFIG_HVM.
Signed-off-by: Wei Liu
---
v3: Put pod relat
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
---
v3:
1. return EOPNOUTSUPP instead of 0
2. fix style issue
---
xen/arch/x86/Makefile | 2 +-
xen/include/asm-x86/monitor.h | 13 +
2 file
Use these flags in has_* tests and emulation_flags_ok.
Not using raw flags directly enabling DCE to kick in for has_* tests
while at the same time making sure emulation_flags_ok won't go out of
sync.
Signed-off-by: Wei Liu
---
v3: new
---
xen/arch/x86/domain.c| 13 ++
xen/includ
Move enum and function declarations to first half of the file.
Static inline functions and macros, which reference HVM specific
fields directly are grouped together in second half of the file.
The movement is needed because in a later patch the second half is
going to be enclosed in CONFIG_HVM.
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
Reviewed-by: Kevin Tian
Acked-by: Boris Ostrovsky
---
xen/arch/x86/hvm/svm/svm.c | 14 +++---
xen/arch/x86
Make sure hvm_enabled evaluate to false then provide necessary things
to make xen build when !CONFIG_HVM.
Signed-off-by: Wei Liu
---
v3: rewritten
---
xen/include/asm-x86/hvm/hvm.h | 97 +++
1 file changed, 97 insertions(+)
diff --git a/xen/include/asm-x8
This series goes through x86 code to make CONFIG_HVM work.
With this series, it is possible to build Xen with PV support only.
Running `xl info` on a host with PV only Xen:
root@lcy2-dt108:~# xl info
host : lcy2-dt108
release: 4.17.0-0.bpo.1-amd64
version
Previously PoD target was unconditionally set for both PV and HVM
guests, but in fact PoD has always been an HVM (now PVH as well) only
feature.
Signed-off-by: Wei Liu
---
tools/libxl/libxl_mem.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/tools/l
Put the entire case branch under CONFIG_HVM.
Nonetheless check HVM before trying to get ioreq server.
Signed-off-by: Wei Liu
---
v3:
1. put an assert in hvm_get_ioreq_server_frame
2. remove redundant assignment of rc
v2: put entire case branch under CONFIG_HVM
---
xen/arch/x86/hvm/ioreq.c | 5
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 04 September 2018 17:15
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Paul Durrant ;
> Jan Beulich ; Andrew Cooper
>
> Subject: [PATCH v3 03/16] x86: XENMEM_resource_ioreq_server is HVM
> only
>
> Put the ent
On 04/09/18 17:11, Juergen Gross wrote:
> On 16/08/18 13:27, Jan Beulich wrote:
> On 16.08.18 at 12:56, wrote:
>>> On 16/08/18 11:29, Jan Beulich wrote:
Following some further discussion with Andrew, he looks to be
convinced that the issue is to be fixed in the balloon driver,
w
Nested HVM is not enabled when !CONFIG_HVM.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm/paging.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index dcee496eb0..7f460bd321 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/pagin
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
xen/common/domain.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78c450e4b4..1f95bd169c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -318,9 +318,24 @@ struct
Signed-off-by: Wei Liu
---
v3: longer text
v2: use tab to indent
Haven't added a dependency on PV_SHIM_EXCLUSIVE because agreement is
not yet reached.
---
xen/arch/x86/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index ae1b7
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
---
tools/firmware/xen-dir/shim.config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/xen-dir/shim.config
b/tools/firmware/xen-dir/shim.config
index 21d7075bb4..de53dfe376 100644
--- a/tools/firmware/xen-dir
HVM and IOMMU are two distinct hardware features, yet they were
bundled together in sysctl and xl's output.
Decouple them on sysctl level. On toolstack level we still need to
maintain a sensible semantics for `xl info`. Massage the information
according to the following table:
pv hvm iom
These functions are only useful for nested hvm, which isn't enabled
when CONFIG_HVM is false.
Enclose relevant code and fields in CONFIG_HVM. Guard np2m_schedule
with nestedhvm_enabled.
Signed-off-by: Wei Liu
---
xen/arch/x86/domain.c| 6 --
xen/arch/x86/mm/p2m.c| 18 ++
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.
Altp2m requires a bit more attention because its code is embedded in
generic x86 p2m code.
Also make hap_enabled evaluate
On 9/4/18 7:15 PM, Wei Liu 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
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen
On Tue, Sep 04, 2018 at 05:15:20PM +0100, Wei Liu wrote:
> Put the entire case branch under CONFIG_HVM.
>
> Nonetheless check HVM before trying to get ioreq server.
The wording here is confusing. It should have been written as:
Lift the check from hvm_get_ioreq_server_frame into its caller.
Wei
ore trace confirms:
>
> IN 0x24bd9a0 20180904 04:36:32 WRITE (control/sysrq )
> OUT 0x24bd9a0 20180904 04:36:32 ERROR (EACCES )
>
> The problem seems to be in the fact that we don't pre-create control/sysrq
> xenstore node and libxl_send_sysrq() doing libxl__xs_printf() c
On Wed, Aug 29, 2018 at 02:22:05PM +0200, Olaf Hering wrote:
> On Mon, Aug 27, Olaf Hering 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:
> > t
On 9/4/18 7:15 PM, Wei Liu wrote:
> Populate-on-demand is HVM only.
>
> Provide a bunch of stubs for common p2m code and guard one invocation
> of guest_physmap_mark_populate_on_demand with is_hvm_domain.
>
> Put relevant fields in p2m_domain and code which touches those fields
> under CONFIG_HVM
On 9/4/18 8:08 PM, Razvan Cojocaru wrote:
> On 9/4/18 7:15 PM, Wei Liu wrote:
>> Populate-on-demand is HVM only.
>>
>> Provide a bunch of stubs for common p2m code and guard one invocation
>> of guest_physmap_mark_populate_on_demand with is_hvm_domain.
>>
>> Put relevant fields in p2m_domain and co
On 9/4/18 7:15 PM, 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.
>
> Altp2m requires a bit more attention because its code is embedded in
> generic
On 04/09/18 18:01, Anthony PERARD wrote:
> On Wed, Aug 29, 2018 at 02:22:05PM +0200, Olaf Hering wrote:
>> On Mon, Aug 27, Olaf Hering wrote:
>>
>>> Since about two weeks, no released qemu can be built against
>>> xen.git#staging. The error looks like that:
>>> qemu-20180825T130857.235c82acca/incl
Hi Wei,
On 09/04/2018 05:15 PM, Wei Liu wrote:
Populate-on-demand is HVM only.
Provide a bunch of stubs for common p2m code and guard one invocation
of guest_physmap_mark_populate_on_demand with is_hvm_domain.
Put relevant fields in p2m_domain and code which touches those fields
under CONFIG_H
This patch adds image size and flags to XEN image header. It uses
those fields according to the updated Linux kernel image definition.
With this patch bootloader can now place XEN image anywhere in system
RAM at 2MB aligned address without to worry about relocation.
For instance, it fixes the XEN
in control/sysrq
>>
>> xenstore trace confirms:
>>
>> IN 0x24bd9a0 20180904 04:36:32 WRITE (control/sysrq )
>> OUT 0x24bd9a0 20180904 04:36:32 ERROR (EACCES )
>>
>> The problem seems to be in the fact that we don't pre-create control/sysrq
>
xen_swiotlb_{alloc,free}_coherent() actually allocate/free size by order
but used the required size to check if address is physical contiguous,
if first pages are physical contiguous also passed
range_straddles_page_boundary() check, but others were not it will
lead kernel panic.
Signed-off-by: Jo
flight 127269 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127269/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 089f9be25f4bb445f68241ba05ab4e17786e21a7
baseline version:
xtf f3702a5d29e94814991988
On 13/08/18 11:01, Andrew Cooper wrote:
> This is in preparation to set up d->max_cpus and d->vcpu[] in domain_create(),
> and allow later parts of domain construction to have access to the values.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Gra
On Tue, Sep 04, 2018 at 11:16:58AM -0700, Joe Jin wrote:
> xen_swiotlb_{alloc,free}_coherent() actually allocate/free size by order
> but used the required size to check if address is physical contiguous,
> if first pages are physical contiguous also passed
> range_straddles_page_boundary() check,
Having multiple externs in arch headers is not a good way to provide
a common interface.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 3 ---
arch/arm64/include/asm/io.h | 3 ---
arch/x86/include/asm/io.h | 5 -
include/xen/xen.h | 4
4 files changed, 4
No need to expose these helpers outside the block layer.
Signed-off-by: Christoph Hellwig
---
block/blk.h| 19 +++
include/linux/blkdev.h | 19 ---
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/block/blk.h b/block/blk.h
index 441c2de
Now that we don't need an override for BIOVEC_PHYS_MERGEABLE there is
no need to drag this header in.
Signed-off-by: Christoph Hellwig
---
include/linux/bio.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/bio.h b/include/linux/bio.h
index fcb5f5618ed4..3af2fea686a9 100644
-
Nothing Xen specific in these headers, which get included from a lot
of code in the kernel. So prune the includes and move them to the
Xen-specific files that actually use them instead.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 1 -
arch/arm64/include/asm/io.h
Turn the macro into an inline, move it to blk.h and take the Xen check
into the core code instead of delegating it to architectures.
Also rename the function to biovec_phys_mergeable as there is no need
to shout.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 4
arch/a
No need to pull in the BUG() defintion.
Signed-off-by: Christoph Hellwig
---
include/linux/bio.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 3af2fea686a9..85f2e56ecdb8 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -21,7 +21,6
Keep it close to the actual users instead of exposing the function to all
drivers.
Signed-off-by: Christoph Hellwig
---
block/blk-merge.c | 65 +++
include/linux/blkdev.h | 69 --
2 files changed, 65 insertions(+),
1 - 100 of 129 matches
Mail list logo
