On Thu, Sep 27, 2018 at 11:25:51AM +0200, David Hildenbrand wrote:
> Reviewed-by: Pavel Tatashin
> Reviewed-by: Rashmica Gupta
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
___
Xen-devel mailing list
Xen-d
On Thu, Sep 27, 2018 at 11:25:54AM +0200, David Hildenbrand wrote:
> Cc: Jonathan Corbet
> Cc: Michal Hocko
> Cc: Andrew Morton
> Reviewed-by: Pavel Tatashin
> Reviewed-by: Rashmica Gupta
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
___
On Thu, Sep 27, 2018 at 11:25:49AM +0200, David Hildenbrand wrote:
> Reviewed-by: Pavel Tatashin
> Reviewed-by: Rafael J. Wysocki
> Reviewed-by: Rashmica Gupta
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
On Thu, Sep 27, 2018 at 11:25:50AM +0200, David Hildenbrand wrote:
> Reviewed-by: Pavel Tatashin
> Reviewed-by: Rafael J. Wysocki
> Reviewed-by: Rashmica Gupta
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
_
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pygrub
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tre
On 2018-10-04 20:21, Michal Hocko wrote:
On Wed 03-10-18 19:09:39, Arun KS wrote:
[...]
+static int online_pages_blocks(unsigned long start, unsigned long
nr_pages)
+{
+ unsigned long end = start + nr_pages;
+ int order, ret, onlined_pages = 0;
+
+ while (start < end) {
+
>>> On 04.10.18 at 18:36, wrote:
> I still think an implicit domain_crash() doesn't really belong in something
> that looks like a straightforward wrapper around a per-implementation jump
> table. How about iommu_map/unmap_may_crash() instead to highlight the
> semantic?
If anything then the o
On 04/10/2018 19:50, Michal Suchánek wrote:
> On Thu, 4 Oct 2018 17:45:13 +0200
> David Hildenbrand wrote:
>
>> On 04/10/2018 17:28, Michal Suchánek wrote:
>
>>>
>>> The state of the art is to determine what to do with hotplugged
>>> memory in userspace based on platform and virtualization type.
>>> On 04.10.18 at 18:42, wrote:
> It is discovered that hvm_funcs made it into monitor.o even when HVM
> is disabled. This version of clang doesn't seem to completely
> eliminate the code after is_hvm_domain() in
> arch_monitor_get_capabilities().
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beuli
>>> On 04.10.18 at 17:52, wrote:
> On 10/04/2018 04:45 PM, Jan Beulich wrote:
> On 04.10.18 at 17:34, wrote:
>>> On 10/04/2018 04:20 PM, Jan Beulich wrote:
>>> On 04.10.18 at 16:56, wrote:
> The biggest problem here is p2m->logdirty_ranges. This patch will
> (justly) not work, be
They not only increase the code footprint, they actually make things
slower rather than faster. Remove them as contemporary hardware doesn't
need any hint.
Suggested-by: Dan Williams
Signed-off-by: Arun KS
---
mm/page_alloc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --gi
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of o
>>> On 04.10.18 at 18:40, wrote:
> On 10/4/18 7:04 PM, Jan Beulich wrote:
> On 02.10.18 at 17:17, wrote:
>>> static void ept_enable_pml(struct p2m_domain *p2m)
>>> {
>>> +struct domain *d = p2m->domain;
>>> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>>> +
>>> +p2m_lock(ho
On Mon, Sep 24, 2018 at 11:55:29AM +0100, Andrew Cooper wrote:
> In practice, this allows the compiler to replace the loop with a pair of movs.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mai
On Mon, Sep 24, 2018 at 11:55:30AM +0100, Andrew Cooper wrote:
> It is MASK_EXTR() in disguise, but less flexible.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xen
Hi All,
I am booting XEN for the first time on my platform and observing that PCIe are
not working.
Here are my observations on this.
1) "git-its" node (below) from device tree is not available in DOM0 device tree.
its: gic-its@602 {
compatible = "ar
On 10/5/18 11:17 AM, Jan Beulich wrote:
On 04.10.18 at 18:40, wrote:
>> On 10/4/18 7:04 PM, Jan Beulich wrote:
>> On 02.10.18 at 17:17, wrote:
static void ept_enable_pml(struct p2m_domain *p2m)
{
+struct domain *d = p2m->domain;
+struct p2m_domain *hostp2m =
>>> On 05.10.18 at 10:41, wrote:
> On 10/5/18 11:17 AM, Jan Beulich wrote:
> On 04.10.18 at 18:40, wrote:
>>> On 10/4/18 7:04 PM, Jan Beulich wrote:
>>> On 02.10.18 at 17:17, wrote:
> static void ept_enable_pml(struct p2m_domain *p2m)
> {
> +struct domain *d = p2m->doma
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 October 2018 08:33
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Jun Nakajima ; Stefano
> Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim
Hi Stefano,
On 10/04/2018 10:52 PM, Stefano Stabellini wrote:
On Wed, 1 Aug 2018, Jan Beulich wrote:
On 01.08.18 at 01:28, wrote:
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen
On 10/05/2018 10:25 AM, Julien Grall wrote:
On 10/04/2018 10:52 PM, Stefano Stabellini wrote:
On Wed, 1 Aug 2018, Jan Beulich wrote:
On 01.08.18 at 01:28, wrote:
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of th
flight 128373 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128373/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 broken
Tests which
Hi All,
Further looking into XEN I found that " CONFIG_HAS_ITS" is not set, so the DOM0
device tree is not having git-its node.
While I do not see a way using make menuconfig to enable CONFIG_HAS_ITS.
Thanks
-Bharat
> -Original Message-
> From: Bharat Bhushan
> Sent: Friday, October 5,
flight 75355 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75355/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2
apparently is no longer sure that "port" is indeed initialized at
if ( sched_poll->nr_ports == 1 )
v->poll_evtchn = port;
It doesn't look to be impossible for the compiler to prove it is not,
but we also can't re
The header is (hence its name) supposed to be a helper for the per-arch
p2m.h files. It was never supposed to be included directly, and for the
purpose of putting common function declarations into the common header
it is more helpful if things like p2m_t are already available at the
inclusion point
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 October 2018 11:14
> To: xen-devel
> Cc: Julien Grall ; Andrew Cooper
> ; Paul Durrant ; Wei
> Liu ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; Konrad Rzeszutek Wilk ;
> Tim (Xen.org)
> Subject: [PA
It's dead code in that case.
We could go further, as we don't really need the 2- and 3-level walk
code in PV mode, but to drop their compilation requires quite a bit of
disentangling of shadow mode code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@
>>> On 05.10.18 at 12:21, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 October 2018 11:14
>> To: xen-devel
>> Cc: Julien Grall ; Andrew Cooper
>> ; Paul Durrant ; Wei
>> Liu ; George Dunlap ; Ian
>> Jackson ; Stefano Stabellini
>> ; Konrad Rzes
Hi,
On 10/05/2018 11:14 AM, Jan Beulich wrote:
The header is (hence its name) supposed to be a helper for the per-arch
p2m.h files. It was never supposed to be included directly, and for the
purpose of putting common function declarations into the common header
it is more helpful if things like
On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote:
> Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2
> apparently is no longer sure that "port" is indeed initialized at
>
> if ( sched_poll->nr_ports == 1 )
> v->poll_evtchn = port;
>
> It doesn't look
Re-adding the cc-list...
> -Original Message-
> From: Paul Durrant
> Sent: 05 October 2018 11:27
> To: George Dunlap
> Subject: RE: [Xen-devel] [PATCH v14 4/9] iommu: don't domain_crash()
> inside iommu_map/unmap_page()
>
> > -Original Message-
> > From: George Dunlap
> > Sent: 0
On 05/10/18 11:20, Jan Beulich wrote:
> It's dead code in that case.
>
> We could go further, as we don't really need the 2- and 3-level walk
> code in PV mode, but to drop their compilation requires quite a bit of
> disentangling of shadow mode code.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/a
Re-cc’ing xen-devel...
> On Oct 5, 2018, at 11:34 AM, George Dunlap wrote:
>
>
>
>> On Oct 5, 2018, at 11:27 AM, Paul Durrant wrote:
>>
>>> -Original Message-
>>> From: George Dunlap
>>> Sent: 05 October 2018 11:25
>>> To: Paul Durrant
>>> Subject: Re: [Xen-devel] [PATCH v14 4/9] io
> -Original Message-
> From: George Dunlap
> Sent: 05 October 2018 11:35
> To: Paul Durrant
> Subject: Re: [Xen-devel] [PATCH v14 4/9] iommu: don't domain_crash()
> inside iommu_map/unmap_page()
>
>
>
> > On Oct 5, 2018, at 11:27 AM, Paul Durrant
> wrote:
> >
> >> -Original Message
Got this one-off crash while booting staging (d36b770458) on a skylake
server. After rebooting it went away.
(XEN) Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at
irq.c:1173
(XEN) [ Xen-4.12-unstable x86_64 debug=y Tainted: C ]
(X
On Fri, Oct 05, 2018 at 04:20:53AM -0600, Jan Beulich wrote:
> It's dead code in that case.
>
> We could go further, as we don't really need the 2- and 3-level walk
> code in PV mode, but to drop their compilation requires quite a bit of
> disentangling of shadow mode code.
>
> Signed-off-by: Jan
On 9/27/18 2:25 PM, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather where
> the fault originated. The npfec.kind value is always valid, and
> should thus be propagated, regardless of whethe
On 10/5/18 12:01 PM, Jan Beulich wrote:
On 05.10.18 at 10:41, wrote:
>> On 10/5/18 11:17 AM, Jan Beulich wrote:
>> On 04.10.18 at 18:40, wrote:
On 10/4/18 7:04 PM, Jan Beulich wrote:
On 02.10.18 at 17:17, wrote:
>> static void ept_enable_pml(struct p2m_domain *p2m)
>>
On 05/10/18 11:48, Wei Liu wrote:
> Got this one-off crash while booting staging (d36b770458) on a skylake
> server. After rebooting it went away.
>
> (XEN) Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at
> irq.c:1173
> (XEN) [ Xen-4.12-unstable x86_64 debug=y Tai
Further update:
If I change Kconfig to enable this default
Then DOM0 Linux Boots but MSIs are not still working,
Getting below error:
- pci 0001:00:00.0: Failed to add - passthrough or MSI/MSI-X might fail!
Any help is very useful,!!
Thanks
-Bharat
> -Original Message-
> From: Xen-de
Older gcc, despite eliminating pci_clean_dpci_irqs() when !HVM, does
not manage to also eliminate pci_clean_dpci_irq(). Cope with this.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/irq.h
+++ b/xen/include/asm-x86/hvm/irq.h
@@ -180,7 +180,15 @@ int pt_pirq_iterate(struct domain *d,
On Fri, Oct 05, 2018 at 05:11:55AM -0600, Jan Beulich wrote:
> Older gcc, despite eliminating pci_clean_dpci_irqs() when !HVM, does
> not manage to also eliminate pci_clean_dpci_irq(). Cope with this.
Would be helpful to call out the version of gcc is the commit message.
Reviewed-by: Wei Liu
__
>>> On 05.10.18 at 12:38, wrote:
>> From: George Dunlap
>> Sent: 05 October 2018 11:35
>>
>> > On Oct 5, 2018, at 11:27 AM, Paul Durrant
>> wrote:
>> > But for mapping too? It seems unnecessary to crash the domain in that
>> case.
>>
>> ISTR that the domain_crash() was added only a few years ag
>>> On 05.10.18 at 12:28, wrote:
> On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote:
>> Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2
>> apparently is no longer sure that "port" is indeed initialized at
>>
>> if ( sched_poll->nr_ports == 1 )
>> v-
>>> On 05.10.18 at 12:32, wrote:
> On 05/10/18 11:20, Jan Beulich wrote:
>> It's dead code in that case.
>>
>> We could go further, as we don't really need the 2- and 3-level walk
>> code in PV mode, but to drop their compilation requires quite a bit of
>> disentangling of shadow mode code.
>>
>>
On Fri, Oct 05, 2018 at 05:22:29AM -0600, Jan Beulich wrote:
> >>> On 05.10.18 at 12:28, wrote:
> > On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote:
> >> Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2
> >> apparently is no longer sure that "port" is indeed ini
>>> On 05.10.18 at 13:14, wrote:
> On Fri, Oct 05, 2018 at 05:11:55AM -0600, Jan Beulich wrote:
>> Older gcc, despite eliminating pci_clean_dpci_irqs() when !HVM, does
>> not manage to also eliminate pci_clean_dpci_irq(). Cope with this.
>
> Would be helpful to call out the version of gcc is the
This is not used (and probably was never meant to be) by the tool stack.
Limiting it to the current domain in particular allows to eliminate a
bogus use of vCPU 0 in pagetable_dying().
Remove the now unnecessary domain/vCPU parameters from the wrapper/hook
functions at the same time.
Signed-off-b
A few pieces of the handling here are (no longer?) vendor specific, and
hence there's no point in replicating the code. Make sure not otherwise
pre-filled fields of struct hvm_hw_cpu instances are zero filled before
calling the vendor "save" hook, eliminating the need for the hook
functions to zero
>>> On 05.10.18 at 12:48, wrote:
> Let me know what else is needed.
The simple addition on top of what Andrew has said: A reliable
repro ;-)
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/
On Fri, Oct 05, 2018 at 05:35:13AM -0600, Jan Beulich wrote:
> >>> On 05.10.18 at 12:48, wrote:
> > Let me know what else is needed.
>
> The simple addition on top of what Andrew has said: A reliable
> repro ;-)
If I had managed to find one I would have debugged this myself. :-)
Wei.
>
> Jan
On 05/10/18 12:25, Wei Liu wrote:
> On Fri, Oct 05, 2018 at 05:22:29AM -0600, Jan Beulich wrote:
> On 05.10.18 at 12:28, wrote:
>>> On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote:
Now that CONFIG_HVM can (and should) be turned off for the shim, gcc 8.2
apparently is no l
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 October 2018 12:18
> To: George Dunlap ; Paul Durrant
>
> Cc: Andrew Cooper ; Ian Jackson
> ; Wei Liu ; Stefano
> Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> S
>>> On 05.10.18 at 13:43, wrote:
> On 05/10/18 12:25, Wei Liu wrote:
>> On Fri, Oct 05, 2018 at 05:22:29AM -0600, Jan Beulich wrote:
>> On 05.10.18 at 12:28, wrote:
On Fri, Oct 05, 2018 at 04:12:10AM -0600, Jan Beulich wrote:
> Now that CONFIG_HVM can (and should) be turned off for t
On 05/10/18 12:29, Jan Beulich wrote:
> This is not used (and probably was never meant to be) by the tool stack.
> Limiting it to the current domain in particular allows to eliminate a
> bogus use of vCPU 0 in pagetable_dying().
>
> Remove the now unnecessary domain/vCPU parameters from the wrapper
On 10/5/18 2:31 PM, Jan Beulich wrote:
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code. Make sure not otherwise
> pre-filled fields of struct hvm_hw_cpu instances are zero filled before
> calling the vendor "save" hook, elim
On 05/10/18 12:26, Jan Beulich wrote:
On 05.10.18 at 13:14, wrote:
>> On Fri, Oct 05, 2018 at 05:11:55AM -0600, Jan Beulich wrote:
>>> Older gcc, despite eliminating pci_clean_dpci_irqs() when !HVM, does
>>> not manage to also eliminate pci_clean_dpci_irq(). Cope with this.
>> Would be helpfu
>>> On 05.10.18 at 13:58, wrote:
> On 05/10/18 12:29, Jan Beulich wrote:
>> This is not used (and probably was never meant to be) by the tool stack.
>> Limiting it to the current domain in particular allows to eliminate a
>> bogus use of vCPU 0 in pagetable_dying().
>>
>> Remove the now unnecessar
On 05/10/18 12:31, Jan Beulich wrote:
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code.
EFER probably was vendor specific originally. The control registers
really shouldn't have been...
> Make sure not otherwise
> pre-fill
On 03/10/18 19:38, Andrew Cooper wrote:
> Finally, this series doesn't link with the default Debian toolchain.
>
> andrewcoop@andrewcoop:/local/xen.git/xen$ ld --version
> GNU ld (GNU Binutils for Debian) 2.25
>
> andrewcoop@andrewcoop:/local/xen.git/xen$ make -s build -j8
> XEN_TARGET_ARCH=x86_64
flight 128415 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128415/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 10/5/18 7:31 AM, Jan Beulich wrote:
> A few pieces of the handling here are (no longer?) vendor specific, and
> hence there's no point in replicating the code. Make sure not otherwise
> pre-filled fields of struct hvm_hw_cpu instances are zero filled before
> calling the vendor "save" hook, elim
Hi,
On 05/10/2018 12:06, Bharat Bhushan wrote:
Further update:
If I change Kconfig to enable this default
CONFIG_HAS_ITS is in tech preview. For having access to it, you need to
pass XEN_CONFIG_EXPERT on *all* the make command line.
Then DOM0 Linux Boots but MSIs are not still working,
Ge
1: add FPU/SIMD register state test
2: extend FPU exception tests
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 05.10.18 at 14:18, wrote:
> On 05/10/18 12:31, Jan Beulich wrote:
>> A few pieces of the handling here are (no longer?) vendor specific, and
>> hence there's no point in replicating the code.
>
> EFER probably was vendor specific originally. The control registers
> really shouldn't have b
Add tests to verify that
- FPU insns leave correct (guest) values in FIP/FDP/FOP/FCS/FDS (at the
example for FSTPS),
- FPU insns writing memory don't update FPU register state when the
write faults (at the example of FISTPS),
- VCVTPS2PH doesn't update MXCSR if its write faults (VCVTPS2PH is on
Also test #MF and #XM handling.
Signed-off-by: Jan Beulich
---
v4: Re-base.
v3: New.
--- /dev/null
+++ b/arch/x86/include/arch/simd.h
@@ -0,0 +1,32 @@
+#ifndef XTF_X86_SIMD_H
+#define XTF_X86_SIMD_H
+
+#define X86_MXCSR_IE 0x0001
+#define X86_MXCSR_DE 0x0002
+#define X86_MXCSR_
flight 128413 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128413/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 8f45b071b58d4a00be551ddcc52e78a06ed6fbc7
baseline version:
freebsd a16e14a2bb8
On 05/10/18 14:28, Jan Beulich wrote:
> 1: add FPU/SIMD register state test
> 2: extend FPU exception tests
>
> Signed-off-by: Jan Beulich
Thanks. However, I need to get the incremental test version logic
working first, or OSSTest will block this on older versions of Xen, due
to (falsely) believ
Paul Durrant (2):
x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once
x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN
xen/arch/x86/hvm/hvm.c | 2 ++
xen/arch/x86/hvm/ioreq.c | 50 ++--
xen/include/asm-x86/h
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the
GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and
HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be used
by (non-default) ioreq servers.
NOTE: This fixes a compatibility issue. A guest cre
>>> On 05.10.18 at 14:39, wrote:
> On 03/10/18 19:38, Andrew Cooper wrote:
>> Finally, this series doesn't link with the default Debian toolchain.
>>
>> andrewcoop@andrewcoop:/local/xen.git/xen$ ld --version
>> GNU ld (GNU Binutils for Debian) 2.25
>>
>> andrewcoop@andrewcoop:/local/xen.git/xen$ m
These parameters should have always been in the 'set once' category
but this has, so far, not been enforced.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/hvm/hvm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/
>>> On 05.10.18 at 15:39, wrote:
> On 05/10/18 14:28, Jan Beulich wrote:
>> 1: add FPU/SIMD register state test
>> 2: extend FPU exception tests
>>
>> Signed-off-by: Jan Beulich
>
> Thanks. However, I need to get the incremental test version logic
> working first, or OSSTest will block this on
flight 128388 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128388/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
in 128363 pass in 128388
test-amd64-
>>> On 04.10.18 at 12:45, wrote:
> The name 'need_iommu()' is a little confusing as it suggests a domain needs
> to use the IOMMU but something might not be set up yet, when in fact it
> represents a tri-state value (not a boolean as might be expected) where
> -1 means 'IOMMU mappings being set up
On 05/10/18 14:43, Jan Beulich wrote:
On 05.10.18 at 14:39, wrote:
>> On 03/10/18 19:38, Andrew Cooper wrote:
>>> Finally, this series doesn't link with the default Debian toolchain.
>>>
>>> andrewcoop@andrewcoop:/local/xen.git/xen$ ld --version
>>> GNU ld (GNU Binutils for Debian) 2.25
>>>
>
To fix an order-of-construction issue with gic-v3 on ARM, arrange for
d->max_vcpus to be auditied and set up prior to arch_domain_create()
This is RFC because all of the interesting changes are in ARM, and therefore
only compile tested by me at this point.
This can be found in git tree from from:
With config->max_vcpus now being audited by the check_domain_config() path, we
can alloate d->vcpu[] before calling arch_domain_create().
Doing do allows for the removal of domain_max_vcpus(), which on the ARM side
removes vgic_max_vcpus() and the .max_vcpus field from vgic_ops.
Signed-off-by: An
This reverts commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db. The domain
creation logic has been adjusted to set up d->max_vcpus early enough to be
usable in vgic_v3_domain_init().
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/vgic-v3.c | 29 ++-
Call it from the head of domain_create() (before doing any memory
allocations), which will apply the checks to dom0 as well as domU's.
For now, just subsume the XEN_DOMCTL_CDF_* check from XEN_DOMCTL_createdomain.
This means that the corner case of the toolstack providing bad configuration
will bu
The purpose of this is to move the auduting to be earlier than
arch_domain_create().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
The max_vcpus setting for GIC_V3 is somewhat confusing. The current GIC_V3
driver claims to support 4096
On the ARM side, lift the code to select the appropriate GIC version when
NATIVE is requested.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/domain.c | 44
xen/arch/x86/doma
>>> On 05.10.18 at 16:49, wrote:
> On 05/10/18 14:43, Jan Beulich wrote:
> On 05.10.18 at 14:39, wrote:
>>> On 03/10/18 19:38, Andrew Cooper wrote:
Makefile:136: recipe for target '/local/xen.git/xen/xen' failed
make[1]: *** [/local/xen.git/xen/xen] Error 2
Makefile:45: recipe
[resending]
On Fri, Oct 5, 2018 at 4:17 PM George Dunlap wrote:
>
> On Mon, Sep 24, 2018 at 9:35 AM Paul Durrant wrote:
> > > +{
> > > +.resource = -1
> >
> > Is -1 guaranteed not to clash with any defined resource type?
>
> Hmm... well at the moment /usr/include/bits/resource.h seem
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 October 2018 15:51
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Andrew Cooper ; Wei Liu ;
> George Dunlap ; Ian Jackson
> ; Jun Nakajima ; Kevin
> Tian ; Stefano Stabellini ;
flight 128422 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128422/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
This patch has broken my PVH Dom0 setup.
[2.515159] igb :02:00.1: added PHC on eth1
[2.519539] igb :02:00.1: Intel(R) Gigabit Ethernet Network Connection
[2.526469] igb :02:00.1: eth1: (PCIe:5.0Gb/s:Width x4) 0c:c4:7a:e7:b6:53
[2.533733] igb :02:00.1: eth1: PBA No:
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 05 October 2018 17:04
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Jun Nakajima ; George
> Dunlap ; Andrew Cooper
> ; Jan Beulich ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH v14
These entries are not always sorted by checkpolicy, so sort them during
policy load (as is already done for later ocontext additions).
Reported-by: Nicolas Poirot
Signed-off-by: Daniel De Graaf
---
xen/xsm/flask/ss/policydb.c | 35 +--
1 file changed, 29 insertio
Limit the ability of a potentially compromised QEMU to consume system
resources. Key limits:
- RLIMIT_FSIZE (file size): 256KiB
- RLIMIT_NPROC (after uid changes to a unique uid)
Probably unnecessary limits but why not:
- RLIMIT_CORE: 0
- RLIMIT_MSGQUEUE: 0
- RLIMIT_LOCKS: 0
- RLIMIT_MEMLOC
docs/qemu-deprivilege.txt had some basic instructions for using
dm_restrict, but it was incomplete, misleading, and stale.
Update the docs in a number of ways.
First, separate user-facing documentation and technical description
into docs/features and docs/design, respectively.
In the feature doc
QEMU running under Xen doesn't need mount or IPC functionality.
Create and enter separate namespaces for each of these before
executing QEMU, so that in the event that other restrictions fail, the
process won't be able to even name system mount points or exsting
non-file-based IPC descriptors to at
Add a tool to check whether the various process-level deprivileging
operations have actually taken place on the process.
The tool takes a domname or domid, and returns success or failure.
Signed-off-by: George Dunlap
---
Changes since v2:
- Make grep for Uid line more strict
- Fix Gid grep, make
When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
* Create /var/run/qemu/root-domid (deleting the old one if it's there)
* Pass the -chroot option to QEMU
Rather than running `rm -rf` on the directory before creating it
(since there is no library function to do this), simpl
When using shadow paging, EFER.NX is a Xen controlled bit, and is required by
the shadow pagefault handler to distinguish instruction fetches from data
accesses.
This can be observed by a guest which has NX and SMEP clear but SMAP active by
attempting to execute code on a user mapping. The first
Signed-off-by: Ian Jackson
---
tools/xentrace/xenalyze.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 5ed0a12327..aa894673ad 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -9224,7
Bastian Blank (1):
tools/xenstat: Fix shared library version
Ian Jackson (17):
docs/man: Fix two typos detected by the Debian lintian tool
tools/xentrace/xenalyze: Fix typos detected by lintian
Various: Fix typos `unkown', `retreive' (detected by lintian)
Various: Fix typo `occured'
Va
Signed-off-by: Ian Jackson
---
tools/python/xen/lowlevel/xc/xc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/python/xen/lowlevel/xc/xc.c
index b137d5a839..6f5b8a6fa8 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/pytho
1 - 100 of 151 matches
Mail list logo
