We have switched to credit2. Let the documentation reflect that.
Signed-off-by: Juergen Gross
---
docs/misc/xen-command-line.pandoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index d39bcee928
On 15/01/2019 12:35, Juergen Gross wrote:
> We have switched to credit2. Let the documentation reflect that.
>
> Signed-off-by: Juergen Gross
And just for the records:
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
> need to call `git submodule`.
>>
>> Fixes b16281870e.
>>
>> Reported-by: Olaf Hering
>> Signed-off-by: Wei Liu
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15/01/2019 12:38, Andrew Cooper wrote:
> On 15/01/2019 11:35, Juergen Gross wrote:
>> We have switched to credit2. Let the documentation reflect that.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> docs/misc/xen-command-line.pandoc | 2 +-
>> 1 f
On 15/01/2019 12:41, Andrew Cooper wrote:
> On 15/01/2019 11:40, Juergen Gross wrote:
>> On 15/01/2019 12:38, Andrew Cooper wrote:
>>> On 15/01/2019 11:35, Juergen Gross wrote:
>>>> We have switched to credit2. Let the documentation reflect that.
>>
On 15/01/2019 16:54, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 1/2] man: Fix links in xl(1)"):
>> All links to other manpages should contain the man section number.
>
> Acked-by: Ian Jackson
Release-acked-by:
joining word like `See', and a full stop, too.
> I still don't know why a cache is needed for it to make it into a
> link. Can we do some seddery to this too ?
>
>
> Anyway, this patch of yours is a big improvement, so:
>
> Acked-by: Ian Jackson
>
On 15/01/2019 21:03, Stewart Hildebrand wrote:
> On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
>> First of all we should explore whether the variables could also be
>> linker generated, in particular to avoid the current symbols to be
>> global (thus making it impossible to access them f
Ian,
with the push this morning I guess we have a good base for 4.12-rc1.
Please cut 4.12-rc1 on current master:
commit 93a62c544e20ba9e141e411bbaae3d65259d13a3
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
On 16/01/2019 01:24, Hans van Kranenburg wrote:
> Hi,
>
> On 1/14/19 1:44 PM, Juergen Gross wrote:
>> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
>> sched_clock() interface") broke Xen guest time handling across
>> migr
On 16/01/2019 00:36, Stefano Stabellini wrote:
> On Tue, 15 Jan 2019, Jan Beulich wrote:
>>> Yes, this instance is only the tip of the
>>> iceberg, we have a long road ahead, but we shouldn't really give up
>>> because it is going to be difficult :-) Stewart's approach would
>>> actually be complia
The syntax for the release note link in SUPPORT.md is wrong. Correct
that.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 98ab52eda9..de388d0afa 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -13,7
The syntax for the release note link in SUPPORT.md is wrong. Correct
that.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 6d417a618e..2ec77bf2cc 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -13,7
On 14/01/2019 15:59, Ian Jackson wrote:
> Some early kernesl are known not to reject unknown flags to
s/kernesl/kernels/
> unshare(). There may be other problems.
>
> CC: Jan Beulich
> Signed-off-by: Ian Jackson
For the series:
Release-acked-by: Juergen G
ivers/passthrough/vtd/x86/vtd.c | 6 -
> xen/drivers/passthrough/x86/iommu.c | 14 +-
> xen/include/xen/iommu.h | 2 +-
> 9 files changed, 197 insertions(+), 264 deletions(-)
>
For the series: Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
y() and nmi(), as
> those code paths are unreachable afaict when running PV Xen guests.
>
> Fixes: 7f2590a110b837af5679d08fc25c6227c5a8c497
> Signed-off-by: Jan Beulich
> Cc: sta...@kernel.org
Reviewed-by: Juergen Gross
Juergen
___
Xen-
u bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
For the Xen part:
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 16/01/2019 14:17, Boris Ostrovsky wrote:
> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
>
>> @@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
>> xen_have_vector_callback = 0;
>>
On 16/01/2019 15:57, George Dunlap wrote:
> On 1/16/19 9:46 AM, Juergen Gross wrote:
>> The syntax for the release note link in SUPPORT.md is wrong. Correct
>> that.
>>
>> Signed-off-by: Juergen Gross > ---
>> SUPPORT.md | 4 +++-
>> 1 file changed, 3 ins
On 16/01/2019 16:07, Boris Ostrovsky wrote:
> On 1/16/19 9:33 AM, Juergen Gross wrote:
>> On 16/01/2019 14:17, Boris Ostrovsky wrote:
>>> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
>>>
>>>> @@ -1650,13 +1
On 16/01/2019 16:45, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH-for-4.10] correct release note link in
> SUPPORT.md"):
>> On 16/01/2019 15:57, George Dunlap wrote:
>>> On 1/16/19 9:46 AM, Juergen Gross wrote:
>>>> +Release-Notes
>>
Hi all,
Xen 4.12 rc1 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12.0-rc1
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc1/xen-4.12.0-rc1.tar.gz
And the signature is at:
https://downloads.xenproject.org/
On 17/01/2019 10:08, Andrew Cooper wrote:
> On 17/01/2019 08:43, Roger Pau Monné wrote:
>> On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
>>> On 16/01/2019 11:52, Jan Beulich wrote:
>>> On 16.01.19 at 10:00, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/
On 17/01/2019 12:59, Jan Beulich wrote:
On 17.01.19 at 10:14, wrote:
>> On 17/01/2019 10:08, Andrew Cooper wrote:
>>> On 17/01/2019 08:43, Roger Pau Monné wrote:
On Wed, Jan 16, 2019 at 07:51:33PM +, Andrew Cooper wrote:
> On 16/01/2019 11:52, Jan Beulich wrote:
> On 16.0
Add "xl get-config" printing the .config used to build the currently
running hypervisor.
Juergen Gross (2):
xen: add interface for obtaining .config from hypervisor
tools: add new xl command get-config for getting hypervisor config
.gitignore | 2 ++
doc
Add a sysctl interface for obtaining the .config file used to build
the hypervisor. The mechanism is inspired by the Linux kernel's one.
Signed-off-by: Juergen Gross
---
.gitignore | 2 ++
tools/flask/policy/modules/dom0.te | 2 +-
xen/common/Mak
Add new subcommand "get-config" to xl config to print the hypervisor
.config file.
To be able to reuse already existing decompressing code in libxenguest
xc_inflate_buffer() has to be moved to libxenguest.h.
Signed-off-by: Juergen Gross
---
docs/man/xl.1.pod.in | 5 ++
On 17/01/2019 16:12, Wei Liu wrote:
> On Thu, Jan 17, 2019 at 03:57:21PM +0100, Juergen Gross wrote:
>> Add a sysctl interface for obtaining the .config file used to build
>> the hypervisor. The mechanism is inspired by the Linux kernel's one.
>>
>&
On 17/01/2019 16:12, Wei Liu wrote:
> On Thu, Jan 17, 2019 at 03:57:22PM +0100, Juergen Gross wrote:
>> Add new subcommand "get-config" to xl config to print the hypervisor
>> .config file.
>
> I slight prefer get-xen-config or get-hypervisor-config.
I'd be
On 17/01/2019 15:57, Juergen Gross wrote:
> Add "xl get-config" printing the .config used to build the currently
> running hypervisor.
BTW: I'd like to have feedback especially if someone thinks this series
should by any means be part of 4.12. If not I'll send out
On 17/01/2019 17:10, anshul wrote:
>
> On 14/09/2017 13:58, Dario Faggioli wrote:
>> On Thu, 2017-09-14 at 08:42 +0200, Juergen Gross wrote:
>>>> --- a/tools/libxc/include/xenctrl.h
>>>> +++ b/tools/libxc/include/xenctrl.h
>>>> @@ -1
ed-by: Jim Fehlig
Signed-off-by: Juergen Gross
Tested-by: Jim Fehlig
---
4.12 is not affected due to Andrew's domain creation interface changes,
4.9 and earlier are not affected due to xc_domain_set_gnttab_limits()
only having been introduced in 4.10.
---
tools/libxl/libxl_create.c | 5 ++
| 2 +-
drivers/xen/pvcalls-back.c | 9 ++--
drivers/xen/pvcalls-front.c | 104 ---
5 files changed, 90 insertions(+), 42 deletions(-)
Juergen Gross (1):
xen: Fix x86 sched_clock() interface for xen
Stefano Stabellini (5):
pvcalls-front
On 18/01/2019 12:38, George Dunlap wrote:
> On 1/17/19 3:23 PM, Juergen Gross wrote:
>> On 17/01/2019 15:57, Juergen Gross wrote:
>>> Add "xl get-config" printing the .config used to build the currently
>>> running hypervisor.
>>
>> BTW: I'd l
On 18/01/2019 14:13, Andrew Cooper wrote:
> On 10/12/2018 11:44, Juergen Gross wrote:
>> With being able to specify a dom0_mem value depending on host memory
>> size on x86 make it easy for distros to specify a default dom0 size by
>> adding a CONFIG_DOM0_MEM item which pres
On 18/01/2019 15:06, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: fix error message for unsharing namespaces"):
>> Signed-off-by: Wei Liu
>
> Thanks. IMO this simple bugfix should go into 4.12.
I agree (while I kind of like the "unfailed" :-)
On 18/01/2019 14:44, Andrew Cooper wrote:
> On 18/01/2019 13:19, Juergen Gross wrote:
>> On 18/01/2019 14:13, Andrew Cooper wrote:
>>> On 10/12/2018 11:44, Juergen Gross wrote:
>>>> With being able to specify a dom0_mem value depending on host memory
>>>&g
On 22/01/2019 00:41, Stefano Stabellini wrote:
> On Mon, 21 Jan 2019, Jan Beulich wrote:
> On 19.01.19 at 00:05, wrote:
>>> On Fri, 18 Jan 2019, Jan Beulich wrote:
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
> On 17.01.19 at 01:37, wrote:
>>
n adding PCI devices due to corresponding ACPI table entries.
Not respecting "mem=" can be corrected by adding a global max_mem_size
variable set by parse_memopt() which will result in rejecting adding
memory areas resulting in a memory size above the allowed limit.
Signed-off-by: Juerg
s problems (e.g. avoiding to add
only parts of a 128MB memory bar which might be difficult to remove
later).
Juergen Gross (2):
x86: respect memory size limiting via mem= parameter
x86/xen: dont add memory above max allowed allocation
arch/x86/kernel/e820.c | 5 +
arch/x86/xen/setup.
75241] [] phys_pmd_init+0x210/0x255
[ 584.681587] [] phys_pud_init+0x1da/0x247
[ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4
[ 584.695682] [] init_memory_mapping+0x18d/0x380
[ 584.702631] [] arch_add_memory+0x59/0xf0
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 5 +
1
On 22/01/2019 09:52, Jan Beulich wrote:
On 22.01.19 at 09:06, wrote:
>> Don't allow memory to be added above the allowed maximum allocation
>> limit set by Xen.
>
> This reads as if the hypervisor was imposing a limit here, but looking at
> xen_get_max_pages(), xen_foreach_remap_area(), and
ve all the bogus scheme "relative" and
> can end up with nice relative links.
>
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Jackson
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 16/01/2019 17:16, Anthony PERARD wrote:
> Provide a better way to see the link to a different manpage, with simple
> words.
>
> Suggested-by: Ian Jackson
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Jackson
Release-acked-by: Juerge
On 22/01/2019 15:35, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Boris Ostrovsky
> Cc: Juergen Gr
y: Roger Pau Monné
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
22 deletions(-)
>
For the series:
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 23/01/2019 13:50, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Taking decision by `need_iommu_pt_sync()` make us never kicking
> `iommu_iotlb_flush()` for IOMMUs which do share P2M with CPU.
> So check `has_iommu_pt()` instead.
>
> Signed-off-by: Andrii Anisov
Rele
we compute it so we know we can
>>> safely using it afterwards.
>>>
>>> Signed-off-by: Julien Grall
>>> Reported-by: Jan-Peter Larsson
>>
>> Reviewed-by: Stefano Stabellini
>
> Would it be possible to give an RAB for this patch?
Relea
On 23/01/2019 15:35, William Kucharski wrote:
>
>
>> On Jan 22, 2019, at 1:06 AM, Juergen Gross wrote:
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index b9a667d36c55..7fc2a87110a3 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/me
offered by the global domheap lock.
>
> As a minor change noticed when checking the safety of this construct, sanity
> check during boot that idle->max_vcpus is a suitable upper bound for
> idle->vcpu[].
>
> Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
for higher order map/unmap
>> operations")
>> Signed-off-by: Roger Pau Monné
>
> I notice you didn't Cc Jürgen - now done.
Thanks.
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
are dropped:
> - Mentioning PV; PV guests never have a device model.
> - Drop the confusing statement about stdvga and cirrus vga options.
> - Re-used domain IDs are now handled.
> - Device models should no longer be able to create world-readable
> files on dom0's fi
he -EOPNOTSUPP part of this
> condition is also wrong.
>
> Drop the !sve check entirely.
>
> Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 28/01/2019 09:28, Jan Beulich wrote:
> Jürgen,
>
On 23.01.19 at 12:51, wrote:
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>> execution on Intel hardware, an lfence instruc
On 28/01/2019 10:56, Jan Beulich wrote:
On 28.01.19 at 09:47, wrote:
>> On 28/01/2019 09:28, Jan Beulich wrote:
>> On 23.01.19 at 12:51, wrote:
This patch series attempts to mitigate the issue that have been raised in
the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.
on on debug builds.
>
> Fixes: ec2a2f1 ("ARM: VGIC: factor out vgic_connect_hw_irq()")
> Signed-off-by: Andrii Anisov
> Suggested-by: Stefan Nuernberger
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing l
t; xen/include/asm-arm/cpufeature.h | 3 +-
> xen/include/asm-arm/processor.h | 2 +
> 8 files changed, 139 insertions(+), 30 deletions(-)
>
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
e that flushing just a single page is
> sufficient: As per verify_patch_size() patch size can't exceed 4k, and
> the way xmalloc() works the blob can't be crossing a page boundary.
>
> Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
Juergen
_
t a time, and
> suspending its monitor (QMP) until the command as been processed and
> sent. Disconnecting from the socket doesn't unsuspend the monitor. The
> race described here is very likely to happen with QEMU 3.1.50 (during
> 3.2 development), but can be reproduced with QEMU 3.1.
> To fix this issue, let's move the deactivate_irq operation just after
> eoi_irq, then the SGI interrupt will be in deactive state when
> smp_call_function_interrupt.
>
> Signed-off-by: Peng Fan
Release-acked-by: Juergen Gross
Juergen
___
I have found an alarming tendency regarding changes in the OSStest
repository: over the last 2 years (or 3 Xen versions) there has been
a pattern of OSStest commits being more frequent during the RC phase
of a Xen release. On average there were about 4 commits to osstest.git
per week. The numbers w
70
>
> In order to solve it move the vioapic_hwdom_map_gsi outside of the
> locked region in vioapic_write_redirent. vioapic_hwdom_map_gsi will
> not access any of the vioapic fields, so there's no need to call the
> function holding the hvm.irq_lock.
>
> Signed-off-by:
rder.
>
> Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ation to produce the header together with the
> directory tree creation therefore does not work. Introduce a separate
> goal.
>
> Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing li
d header if needed, but only when these rules did not
> get invoked recursively themselves.
>
> Finally cpuid.o did not have any dependencies added for it.
>
> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
_
On 29/01/2019 12:37, Wei Liu wrote:
> Tamas reported ssid_label was leaked. Use the designated function to
> free dominfo list to fix the leakage.
>
> Reported-by: Tamas K Lengyel
> Signed-off-by: Wei Liu
> Tested-by: Tamas K Lengyel
Release-acked-by: Juerge
On 29/01/2019 13:43, Ian Jackson wrote:
> Juergen Gross writes ("OSStest commits and Xen releases"):
>> I have found an alarming tendency regarding changes in the OSStest
>> repository: over the last 2 years (or 3 Xen versions) there has been
>> a pattern of OSSt
On 29/01/2019 18:08, osstest service owner wrote:
> flight 132544 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/132544/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemut-stubdo
75241] [] phys_pmd_init+0x210/0x255
[ 584.681587] [] phys_pud_init+0x1da/0x247
[ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4
[ 584.695682] [] init_memory_mapping+0x18d/0x380
[ 584.702631] [] arch_add_memory+0x59/0xf0
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c
s problems (e.g. avoiding to add
only parts of a 128MB memory bar which might be difficult to remove
later).
Changes in V2:
- patch 1: set initial allowed size to U64_MAX instead -1
- patch 2: set initial allowed size to end of E820 RAM
Juergen Gross (2):
x86: respect memory size limiting via mem= para
n adding PCI devices due to corresponding ACPI table entries.
Not respecting "mem=" can be corrected by adding a global max_mem_size
variable set by parse_memopt() which will result in rejecting adding
memory areas resulting in a memory size above the allowed limit.
Signed-off-by: Juerg
On 30/01/2019 14:38, Wei Liu wrote:
> On Wed, Jan 30, 2019 at 12:46:45PM +, Wei Liu wrote:
>> On Wed, Jan 30, 2019 at 12:30:44PM +, Andrew Cooper wrote:
> There are at least two bugs here.
>
> 1) RSDP was a late addition to the PVH boot protocol. Xen's PVH
> entrypoint must
On 30/01/2019 14:55, Wei Liu wrote:
> RSDP is not mandatory according to PVH spec. Remove the BUG_ON. The
> guest (xen) will fall back to scanning if necessary.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Wei Liu
Release-acked-by: Juergen G
On 30/01/2019 11:06, Jan Beulich wrote:
On 30.01.19 at 11:01, wrote:
>> On 30/01/2019 09:57, Jan Beulich wrote:
>> On 29.01.19 at 20:07, wrote:
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -40,7 +40,11 @@
#undef virt_to_mfn
#define virt_to_mfn(v
On 30/01/2019 15:09, Juergen Gross wrote:
> On 30/01/2019 11:06, Jan Beulich wrote:
>>>>> On 30.01.19 at 11:01, wrote:
>>> On 30/01/2019 09:57, Jan Beulich wrote:
>>>>>>> On 29.01.19 at 20:07, wrote:
>>>>> --- a/xen/arch/x86/pv/
where
> warning the user is the wrong course of action to take.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Juergen Gross
>
> v2:
> * Rewrite from scratch, following Juergen's suggestion
>
> An imp
On 31/01/2019 15:07, Jan Beulich wrote:
> This goes alongside Norbert's series, dealing with a few more
> places where I happened to know (without any analysis tools)
> guest controlled array accesses sit. I've additionally also
> checked emul-i8254.c, and I think no adjustments are needed
> there
Now that I've got maintainer acks, could I get a view to 4.12 release
> ack please? This improves diagnostics for a real issue we discovered
> during the 4.12 development cycle.
For the series:
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
While working on my core scheduling series I stumbled over the periodic
timer. Could it be this timer never worked correctly?
When the vcpu with an active periodic timer is running everything seems
to be fine. But when not running the timer is stopped in schedule(). So
a vcpu going to idle relying
On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>>> Hello,
>>>
>>> I am working on porting an out-of-tree kernel driver to the kernel
>>> 5.0 and that driver uses functionality provided by
>>
On 01/02/2019 10:40, Andrew Cooper wrote:
> On 01/02/2019 07:26, Juergen Gross wrote:
>> While working on my core scheduling series I stumbled over the periodic
>> timer. Could it be this timer never worked correctly?
>>
>> When the vcpu with an active periodic timer
On 01/02/2019 10:50, Jan Beulich wrote:
On 01.02.19 at 08:26, wrote:
>> While working on my core scheduling series I stumbled over the periodic
>> timer. Could it be this timer never worked correctly?
>>
>> When the vcpu with an active periodic timer is running everything seems
>> to be fine.
On 01/02/2019 12:14, Jan Beulich wrote:
> All,
>
> both releases would have been due last week. Please point out
> backports you find missing from their respective staging branches,
> but which you consider relevant.
For 4.10.3:
https://lists.xen.org/archives/html/xen-devel/2019-01/msg01451.html
On 01/02/2019 16:02, Wei Liu wrote:
> On Fri, Feb 01, 2019 at 03:59:58PM +0100, Juergen Gross wrote:
>> On 01/02/2019 14:42, Doug Goldstein wrote:
>>> On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote:
>>>> Make qemu-smoke-x86-64.sh take a variant argume
ady raise #GP for the guest.
>
> If svm_get_insn_len() fails, return back to guest context rather than
> continuing and mistaking a trap-style VMExit for a fault-style one.
>
> Spotted by Coverity.
>
> Signed-off-by: Andrew Coo
On 01/02/2019 14:42, Doug Goldstein wrote:
> On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote:
>> Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests
>> in test.yaml.
>>
>> Signed-off-by: Wei Liu
>
> Acked-by: Doug Goldstein
>
> This is a good improvement to increase ou
ned-off-by: Juergen Gross
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/vtd/iommu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index
On 01/02/2019 16:44, Jan Beulich wrote:
On 01.02.19 at 16:13, wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -570,7 +570,7 @@ static void amd_dump_p2m_table(struct domain *d)
>> amd_dump_p2m_table_level(hd->arch.root
returning from system suspend.
As the initialization data is no longer accessible in this case that
second initialization must be dropped in case the system isn't just
booting.
Signed-off-by: Juergen Gross
---
xen/drivers/passthrough/vtd/intremap.c | 4 ++--
1 file changed, 2 insertions(
On 01/02/2019 17:29, Juergen Gross wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems there is another path where
66380
> Cc: Ian Jackson
> Cc: Wei Liu
I think we want that in 4.12. So:
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
t of the
> xenolinux fork which never got upstreamed.
>
> It's utility is zero nowadays. Drop it.
>
> Signed-off-by: Wei Liu
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
Hi all,
Xen 4.12 rc2 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12-rc2
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12-rc2/xen-4.12-rc2.tar.gz
And the signature is at:
https://downloads.xenproject.org/releas
NVAL;
>>>>>> +s = ss + 1;
>>>>>> +} while ( *ss );
>>>>>> +
>>>>>> +/* Selecting bts/ipc/arch forces vpmu to enabled. */
>>>>>> +if ( vpmu_features )
>>>>>> +opt_vpmu_enabled = true;
>>>>> If you want to retain original behavior, the condition here would need
>>>>> to be "!rc && vpmu_features". It's not clear whether your modification
>>>>> in this regard is intentional.
>>>> Oh - that wasn't intentional.
>>>>
>>>> An alternative, now I think about it, is to just have the =false
>>>> case clear vpmu_features. This is new behaviour, but it is more
>>>> consistent with how other options work, and it wasn't expressable before.
>>> Generally - yes. But what would e.g. "vpmu=off,ipc" end up doing in
>>> your new model?
>>
>> The use of vpmu_features is somewhat weird. "bts" acts as an extra
>> feature on top of "generally on", whereas "ipc" and "arch" act as
>> restrictions on top of "generally on".
>
> Okay let's go that route then.
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer.
While at it switch debugtrace_send_to_console and debugtrace_used to
bool and delete an empty line.
Signed-off-by: Juergen
Another debugtrace enhancement I needed for core scheduling debugging.
Juergen Gross (3):
xen: move debugtrace coding to common/debugtrace.c
xen: refactor debugtrace data
xen: add per-cpu buffer option to debugtrace
docs/misc/xen-command-line.pandoc | 7 +-
xen/common/Makefile
unction to accept size modifiers
(e.g. 4M or 1G).
Printing out the trace entries is done for each buffer in order to
minimize the effort needed during printing. As each entry is prefixed
with its sequence number sorting the entries can easily be done when
analyzing them.
Signed-off-by: Jue
Instead of living in drivers/char/console.c move the debugtrace
related coding to a new file common/debugtrace.c
Signed-off-by: Juergen Gross
---
xen/common/Makefile| 1 +
xen/common/debugtrace.c| 177 +
xen/drivers/char/console.c | 176
601 - 700 of 7296 matches
Mail list logo