On Tue, Feb 14, 2017 at 11:42:56AM -0800, Thomas Garnier wrote:
> This patch aligns MODULES_END to the beginning of the Fixmap section.
> It optimizes the space available for both sections. The address is
> pre-computed based on the number of pages required by the Fixmap
> section.
>
> It will all
flight 105814 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105814/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cb8674999c6bf94cdb3be18df3746131aac6386b
baseline version:
ovmf 5e9e151c2061cc10e5aa9
bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
to a new asm/compiler.h to compensate.
While making changes, switch bool_t to bool and use named asm parameters.
No (intended) functional cha
On 15/02/17 14:22, Andrew Cooper wrote:
> bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
> result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
> to a new asm/compiler.h to compensate.
>
> While making changes, switch bool_t to bool and use na
>>> On 15.02.17 at 14:40, wrote:
> On Wed, 2017-02-15 at 06:03 -0700, Jan Beulich wrote:
>> > > > On 15.02.17 at 12:55, wrote:
>> > > > > On 15.02.17 at 12:48, wrote:
>> > >
>> > > On Wed, 2017-02-15 at 04:39 -0700, Jan Beulich wrote:
>> > > > > > > On 15.02.17 at 11:27, wrote:
>> > > > >
>>
flight 105820 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105820/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
wrote:
> So that they're all close among each other, and
> also near to the comment describind the runqueue
> organization (which is also moved).
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
> Cc: An
>>> On 15.02.17 at 15:29, wrote:
On 15.02.17 at 14:40, wrote:
>> On Wed, 2017-02-15 at 06:03 -0700, Jan Beulich wrote:
>>> > > > On 15.02.17 at 12:55, wrote:
>>> > > > > On 15.02.17 at 12:48, wrote:
>>> > >
>>> > > On Wed, 2017-02-15 at 04:39 -0700, Jan Beulich wrote:
>>> > > > > > > On 1
On 02/13/2017 12:03 PM, Paul Durrant wrote:
> Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they
On 02/13/2017 12:03 PM, Paul Durrant wrote:
> The purpose if this ioctl is to allow a user of privcmd to restrict its
> operation such that it will no longer service arbitrary hypercalls via
> IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when
> servicing IOCTL_PRIVCMD_DM_OP. The aim
On Wed, 2017-02-15 at 06:20 -0700, Jan Beulich wrote:
> > > > On 15.02.17 at 11:27, wrote:
> >
> > This is what I'm getting during the original test case (32 VMs reboot):
> >
> > (XEN) [ 1407.789329] Watchdog timer detects that CPU12 is stuck!
> > (XEN) [ 1407.795726] [ Xen-4.6.1-xs-local x
>>> On 15.02.17 at 15:22, wrote:
> bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
> result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
> to a new asm/compiler.h to compensate.
>
> While making changes, switch bool_t to bool and use named a
On Thu, Feb 9, 2017 at 11:48 PM, Dario Faggioli
wrote:
> On Thu, 2017-02-09 at 14:59 +0100, Dario Faggioli wrote:
>> In fact, whether or not a pCPU has been tickled, and is
>> therefore about to re-schedule, is something we look at
>> and base decisions on in various places.
>>
>> So, let's make s
On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
wrote:
> A credit reset basically means going through all the
> vCPUs of a runqueue and altering their credits, as a
> consequence of a 'scheduling epoch' having come to an
> end.
>
> Blocked or runnable vCPUs are fine, all the credits
> they've spent
>>> On 15.02.17 at 15:55, wrote:
On 15.02.17 at 15:22, wrote:
>> bitops.h cannot include asm_defns.h, because the static inlines in
> cpumasks.h
>> result in forward declarations of the bitops.h contents. Move
> ASM_FLAG_OUT()
>> to a new asm/compiler.h to compensate.
>>
>> While making
>>> On 15.02.17 at 15:55, wrote:
> On Wed, 2017-02-15 at 06:20 -0700, Jan Beulich wrote:
>> > > > On 15.02.17 at 11:27, wrote:
>> >
>> > This is what I'm getting during the original test case (32 VMs reboot):
>> >
>> > (XEN) [ 1407.789329] Watchdog timer detects that CPU12 is stuck!
>> > (XEN)
On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
wrote:
> When traversing a Credit2 runqueue to select the
> best candidate vCPU to be run next, show in the
> trace which vCPUs we consider.
>
> A bit verbose, but quite useful, considering that
> we may end up looking at, but then discarding, one
> o
On 02/14/2017 02:42 PM, Thomas Garnier wrote:
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 0dee6f59ea82..6399bab936cd 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -391,7 +391,7 @@ cpu_initialize_context(unsigned int cpu, struct
> task_struct *idle)
> if
On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote:
> Hi Konrad,
>
> Thanks for the feedback.
>
> On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote:
> >> As per "VM System Specification for ARM Processo
On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
wrote:
> In fact, it is quite useful a pice of information,
> to know how long it is the "next time slice" a vCPU
> has been granted. It allows one to assume (and then
> check) when the scheduler is supposed to run next,
> and other things.
>
> While
On Wed, Feb 15, 2017 at 5:58 AM, Borislav Petkov wrote:
>
> On Tue, Feb 14, 2017 at 11:42:56AM -0800, Thomas Garnier wrote:
> > This patch aligns MODULES_END to the beginning of the Fixmap section.
> > It optimizes the space available for both sections. The address is
> > pre-computed based on the
On Wed, Feb 15, 2017 at 7:37 AM, Boris Ostrovsky
wrote:
> On 02/14/2017 02:42 PM, Thomas Garnier wrote:
>> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
>> index 0dee6f59ea82..6399bab936cd 100644
>> --- a/arch/x86/xen/smp.c
>> +++ b/arch/x86/xen/smp.c
>> @@ -391,7 +391,7 @@ cpu_initialize_c
On Tue, Feb 14, 2017 at 7:57 PM, Andy Lutomirski wrote:
> On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote:
>> The KVM segment_base function is confusing. This patch replaces integers
>> with appropriate flags, simplify constructs and add comments.
>
> It could pay to put this first in the
On Wed, Feb 15, 2017 at 09:33:41AM +0200, Oleksandr Andrushchenko wrote:
> On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:
> > > Hi, Konrad!
> > >
> > > Thank you for reviewing this.
> > >
> > > On 02/10/2017 11:27
On Wed, Feb 15, 2017 at 07:40:51AM -0800, Thomas Garnier wrote:
> Why do you think they rely on it being static? The VSYSCALL address is
> not changed for example.
I don't know, that's why I'm asking first. Userspace is known to pick
different aspects of the kernel and deciding to use them for wha
Hi, all.
As it was suggested by Julien in IRC I open this thread.
Currently, I am trying to add support for IPMMU in Xen.
It is VMSA-compatible IOMMU that integrated in the newest Renesas SoCs (ARM).
This IPMMU can't share the page table with the CPU since it uses
stage-1 page table
unlike the CP
Hi Vijay,
On 13/02/17 13:53, Vijay Kilari wrote:
> I tried your patch series on HW. Dom0 boots but no LPIs are coming to Dom0.
> So I made below patch to consider segment ID in generating devid,
> I see below panic from _xmalloc().
I found the root cause of this bug. The size of the ITT entry
On 15/02/17 14:55, Jan Beulich wrote:
On 15.02.17 at 15:22, wrote:
>> bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
>> result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
>> to a new asm/compiler.h to compensate.
>>
>> While making cha
On 14/02/17 17:56, Andrew Cooper wrote:
> On 14/02/17 17:49, George Dunlap wrote:
>> On 14/02/17 17:45, Andrew Cooper wrote:
>>> On 14/02/17 17:42, George Dunlap wrote:
On 13/02/17 11:00, Andrew Cooper wrote:
> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which
> mi
On Thu, Feb 9, 2017 at 1:58 PM, Dario Faggioli
wrote:
> Hello,
>
> This series contains mostly style or cosmetic fixes for Credit2, with the
> following two exceptions:
> - 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6);
> - some tracing improvements (last 3 patches).
>
> M
>>> On 15.02.17 at 17:00, wrote:
> On 15/02/17 14:55, Jan Beulich wrote:
> On 15.02.17 at 15:22, wrote:
>>> bitops.h cannot include asm_defns.h, because the static inlines in
> cpumasks.h
>>> result in forward declarations of the bitops.h contents. Move
> ASM_FLAG_OUT()
>>> to a new asm/co
On Wed, Feb 15, 2017 at 04:49:15PM +0800, Yi Sun wrote:
> Hi all,
>
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel L2 Cache Allocation Technology (L2 CAT) to Xen.
>
> Besides the L2 CAT implementaion, we refactor the psr.c to make it more
> flexible to add new feat
On Wed, Feb 15, 2017 at 05:54:26PM +0800, Zhang Chen wrote:
> Because of some reason, We no longer support COLO kernel proxy.
> So we send this patch set to make Xen use userspace colo-proxy in qemu.
How come it is RFC? It looks quite baked?
___
Xen-dev
>>> On 15.02.17 at 16:52, wrote:
> I think, but I am not 100% sure that we could avoid actions above if
> we would have knowledge about device assignment for particular
> domain before making any updates in P2M.
Well, one could in theory make this work for boot time assigned
devices, but since th
On Wed, Feb 15, 2017 at 05:54:33PM +0800, Zhang Chen wrote:
> We use kernel colo proxy's way to get the checkpoint event
> from qemu colo-compare.
> Qemu colo-compare need add a API to support this(I will add this in qemu).
>
> Signed-off-by: Zhang Chen
> ---
> tools/libxl/libxl_colo.h |
On 15/02/17 09:44, Jan Beulich wrote:
On 14.02.17 at 18:25, wrote:
>> 4. The security team will only issue an advisory if there is a known
>> combination of software in which the vulnerability can be exploited.
>
> Considering the following text, perhaps "may" would end up a little
> less st
On Wed, Nov 23, 2016 at 12:20:45PM +, Lars Kurth wrote:
> Contains items that at some point need to be addressed.
> The items do not directly affect governance.pandoc
>
> Signed-off-by: Lars Kurth
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> governance.todo | 23 +++
> 1
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
+static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
+ int size, uint64_t itt_addr, bool valid)
+{
+uint64_t cmd[4];
+
+cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
+cmd[1] = size
> >> We could split out the following git repos: mini-os, osstest, raisin,
> >> livepatch-build-tools, xtf
, xentesttools/*
> >> In terms of contributions per release, there is more activity than Windows
> >> PV Drivers, which are a separate project.
> >
> > I see what you meant now. That could b
On Wed, Nov 23, 2016 at 12:20:44PM +, Lars Kurth wrote:
> Added TOC
> Re-arranged sections compared to previous version of document
> Added new anchors where needed
> Split Roles section into two sections
>
> The actual content was not changed (with the exception of minor
> typos that I spotte
On Wed, Feb 15, 2017 at 04:49:16PM +0800, Yi Sun wrote:
> This patch creates CAT and CDP feature document in doc/features/. It describes
> key points to implement L3 CAT/CDP and L2 CAT which is described in details in
> Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION
> FEATU
bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
to a new asm/compiler.h to compensate.
While making changes, switch bool_t to bool and use named asm parameters.
No functional change.
Signe
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
noteworthy exception of #PF) occur inside the stub, forward it to the
guest.
Since the exception fixup table entry can't encode the address of the
faulting insn it
>>> On 15.02.17 at 17:37, wrote:
> On 15/02/17 09:44, Jan Beulich wrote:
> On 14.02.17 at 18:25, wrote:
>>> 4. The security team will only issue an advisory if there is a known
>>> combination of software in which the vulnerability can be exploited.
>>
>> Considering the following text, perh
>>> On 15.02.17 at 17:53, wrote:
> bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
> result in forward declarations of the bitops.h contents. Move
> ASM_FLAG_OUT()
> to a new asm/compiler.h to compensate.
>
> While making changes, switch bool_t to bool and use name
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be in
Hi Stefano,
On 14/02/17 20:39, Stefano Stabellini wrote:
On Mon, 30 Jan 2017, Andre Przywara wrote:
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those wh
Callers to xc_cpupool_create() can either request a specific pool id,
or request that Xen do it for them. But at the moment, the
"automatic" selection is indicated by using a magic value, 0. This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupoo
Callers to libxl_cpupool_create() can either request a specific pool
id, or request that Xen do it for them. But at the moment, the
"automatic" selection is indicated by using a magic value, 0. This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpu
Hi Stefano,
On 14/02/17 21:00, Stefano Stabellini wrote:
On Mon, 30 Jan 2017, Andre Przywara wrote:
+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their ta
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
G
flight 105807 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105807/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-xl
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.
Signed-off-by: Andre Prz
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 15 ++-
xen/include/xen/sched.h | 2 +-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/do
Extend the Maptrack comment to point at the Grant table subsystem.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/include/xen/sched.h | 48
1 file changed, 24 insertions(+
Hi, Jan.
On Wed, Feb 15, 2017 at 6:22 PM, Jan Beulich wrote:
On 15.02.17 at 16:52, wrote:
>> I think, but I am not 100% sure that we could avoid actions above if
>> we would have knowledge about device assignment for particular
>> domain before making any updates in P2M.
>
> Well, one could
flight 105822 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 105820
Tests which
On 30/01/17 18:31, Andre Przywara wrote:
Hi,
Hi Andre,
Compared to the previous post (RFC-v2) this has seen a lot of reworks
and cleanups in various areas.
I tried to address all of the review comments, though some are hard to
follow due to rewrites. So apologies if some points have slipped t
xen/config.h includes asm/config.h, and is included automatically via CFLAGS.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/acpi/lib.c| 1 -
xen/arch/arm/arm32/debug.S | 1 -
xen/arch/arm/arm32/head.S | 1 -
xen/arch/arm/arm64/d
generated/autoconf.h is already included automatically so CONFIG_* defines are
avaialble. However, the companion macros such as IS_ENABLED() are not
included.
Include them uniformally everywhere.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xe
flight 105812 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 105807
test-amd64-i386-xl-q
This run is configured for baseline tests only.
flight 68564 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68564/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cb8674999c6bf94cdb3be18df3746131aac6386b
baseline v
The cpu argument in the function prototype of vcpu_is_preempted()
is changed from int to long. That makes it easier to provide a better
optimized assembly version of that function.
For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
downcast from long to int is not a problem as vCPU n
It was found when running fio sequential write test with a XFS ramdisk
on a KVM guest running on a 2-socket x86-64 system, the %CPU times
as reported by perf were as follows:
69.75% 0.59% fio [k] down_write
69.15% 0.01% fio [k] call_rwsem_down_write_failed
67.12% 1.12% fio [k] rwsem_do
v2->v3:
- Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted()
in assembly as suggested by PeterZ.
- Add a new patch to change vcpu_is_preempted() argument type to long
to ease the writing of the assembly code.
v1->v2:
- Rerun the fio test on a different system on both
Hi Andre,
On 01/30/2017 12:31 PM, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to the target CPU.
This mapping is stored in the device and collect
On 02/15/2017 05:45 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 15, 2017 at 09:33:41AM +0200, Oleksandr Andrushchenko wrote:
On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:
Hi, Konrad!
Thank you for reviewing this.
I will apologize up front for my ignorance on the topic of 'Xen' since I
have just been thrown into it. My task at hand is to make modifications to
the Linux kernel so that when the vif on one VHD connected to the
corresponding eth0 on another VHD goes down (ip link set vif1.0 down), eth0
appears
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space
flight 105817 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
104590
Regressio
On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote:
On 15.02.17 at 00:21, wrote:
>> On 14/02/2017 22:47, Tamas K Lengyel wrote:
>>> (XEN) Switched to APIC driver x2apic_cluster.
>>> (XEN) XSM Framework v1.0.0 initialized
>>> (XEN) Flask: 128 avtab hash slots, 394 rules.
>>> (XEN) Flask: 128
On Wed, Feb 15, 2017 at 12:30 PM, Tamas K Lengyel
wrote:
> On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote:
> On 15.02.17 at 00:21, wrote:
>>> On 14/02/2017 22:47, Tamas K Lengyel wrote:
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) XSM Framework v1.0.0 initialized
(X
The now-common hcall_preempted boolean is perfectly usable for multicalls.
Remove the multicall-specific preemption mechanism.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/domain.c | 13 +++--
xen/arch/x86/domain.c
Making PV and HVM guests individually compilable is useful as a reduction in
hypervisor size, and as an aid to enforcing clean API boundaries.
Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do
until either can actually be disabled.
Signed-off-by: Andrew Cooper
---
CC: Jan
HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of
the hypercall in use.
The rest of Xen deals in terms of the comat ABI or not, so rename the boolean
and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI is
not wanted/needed.
Set hcall_compat unif
This original purpose of this work was towards the RFC patch at the end of the
series, but there turned out to be a lot of cleanup opportunity in common and
ARM code as well.
Andrew Cooper (7):
x86/hypercall: Make the HVM hcall_preempted boolean common
arm/hypercall: Use the common hcall_preem
HVM guests currently make use of arch.hvm_vcpu.hcall_preempted to track
hypercall preemption in struct vcpu. Move this boolean to being common at the
top level of struct vcpu, which will allow it to be reused elsewhere.
Alter the PV preemption logic to use this boolean. This simplifies the code
On Wed, 15 Feb 2017, Olaf Hering wrote:
> Am Tue, 14 Feb 2017 20:27:15 +
> schrieb Wei Liu :
>
> > Better to just push to a branch for us to fetch.
>
> That would be git://github.com/olafhering/xen.git#libreoffice
>
> https://github.com/olafhering/xen/commits/libreoffice
>
Thanks, pulled
Repurpose arch/x86/hypercall.c to be common x86 hypercall infrastructure, and
move the PV specific routines to arch/x86/pv/hypercall.c
This is purely code motion.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/Makefile | 1 +
xen/arch/x86/hypercall.c |
The newly-repurposed arch/x86/hypercall.c is a more appropriate place for the
hypercall continuation logic to live.
This is purely code motion.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domain.c| 177 ---
xen/arch/x86/hype
With hcall_preempted having just been made common, ARM can use use it to
simplify its hypercall handling.
This simplifies the continuation logic and removes the risk of accidentally
skipping multiple instructions.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
NB: On
Hi Andre
On 01/30/2017 12:31 PM, Andre Przywara wrote:
Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time
Hi Waiman,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.10-rc8 next-20170215]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Waiman-Long
flight 105816 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 105685
test-amd64-i386
flight 105825 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105825/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
Hey,
Credit goes to Boris (CC-ed) for figuring out how to fix this.
I was doing:
./configure --prefix=/usr --enable-systemd
make -j8
cd dist;./install.sh;)
reboot
and to my surprise it would hang on
Starting Terminate Plymouth Boot Screen"...
On Wed, 15 Feb 2017, Lars Kurth wrote:
> Hi all,
>
> I am kind of stuck on this one and wanted to pick up the discussion again.
> Apologies that it took so long.
>
> To to summarise, we all are agreed on most sections of the proposal,
> with the exception of decision making across projects. One
On 02/15/2017 03:51 PM, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> Credit goes to Boris (CC-ed) for figuring out how to fix this.
>
> I was doing:
>
> ./configure --prefix=/usr --enable-systemd
> make -j8
> cd dist;./install.sh;)
> reboot
>
> and to my surprise it would hang on
> Starting Terminate P
On Wed, Feb 15, 2017 at 04:49:21PM +0100, Borislav Petkov wrote:
> On Wed, Feb 15, 2017 at 07:40:51AM -0800, Thomas Garnier wrote:
> > Why do you think they rely on it being static? The VSYSCALL address is
> > not changed for example.
>
> I don't know, that's why I'm asking first. Userspace is kno
On Wed, 15 Feb 2017, Bhupinder Thakur wrote:
> On 15 February 2017 at 13:45, Bhupinder Thakur
> wrote:
> > Hi Stefano,
> >
> > On 14 February 2017 at 03:14, Stefano Stabellini
> > wrote:
> >> On Mon, 13 Feb 2017, Bhupinder Thakur wrote:
> >>> Hi Stefano,
> >>>
> >>> On 9 February 2017 at 05:40,
On Wed, 15 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 14/02/17 21:00, Stefano Stabellini wrote:
> > On Mon, 30 Jan 2017, Andre Przywara wrote:
> > > +/*
> > > + * Handle incoming LPIs, which are a bit special, because they are
> > > potentially
> > > + * numerous and also only get injected
.snip..
> > > > > I will define 2 sections:
> > > > >*-- Connector Request Transport Parameters
> > > > > ---
> > > > >*
> > > > >* ctrl-event-channel
> > > > >* ctrl-ring-ref
> > > > >*
> > > > >*--- Connector Event Transport
Hi all,
Unfortunately, I have been quite busy over the last few months and did
not manage to finish the patch series, yet. I will continue working in
the next few weeks, however, it is rather unlikely to make the patch
series ready for 4.9.
Cheers
~Sergej
On 02/08/2017 07:59 PM, Tamas K Lengyel
It was found when running fio sequential write test with a XFS ramdisk
on a KVM guest running on a 2-socket x86-64 system, the %CPU times
as reported by perf were as follows:
69.75% 0.59% fio [k] down_write
69.15% 0.01% fio [k] call_rwsem_down_write_failed
67.12% 1.12% fio [k] rwsem_do
The cpu argument in the function prototype of vcpu_is_preempted()
is changed from int to long. That makes it easier to provide a better
optimized assembly version of that function.
For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
downcast from long to int is not a problem as vCPU n
v3->v4:
- Fix x86-32 build error.
v2->v3:
- Provide an optimized __raw_callee_save___kvm_vcpu_is_preempted()
in assembly as suggested by PeterZ.
- Add a new patch to change vcpu_is_preempted() argument type to long
to ease the writing of the assembly code.
v1->v2:
- Rerun the f
On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 19:38, wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -394,10 +394,18 @@ __start:
> >
> > /* EFI IA-32 platforms are not supported. */
> > cmpl$MULTIBOOT2_TA
flight 105819 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10
fail REGR. vs.
This run is configured for baseline tests only.
flight 68563 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68563/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-chec
On Mon, Oct 10, 2016 at 08:34:16AM +0800, Haozhong Zhang wrote:
> When memory-backend-xen is used, the label_data pointer can not be got
> via memory_region_get_ram_ptr(). We will use other functions to get
Could you explain why it cannot be retrieved via that way?
> label_data once we introduce
101 - 200 of 229 matches
Mail list logo
