On 08/11/18 08:08, Juergen Gross wrote:
> On 07/11/2018 10:30, Sander Eikelenboom wrote:
>> Hi Juergen / Boris,
>>
>> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
>> branch pulled on top.
>> Unfortunately i was seeing guests lockup after some time, see below for the
On 08/11/2018 09:14, Sander Eikelenboom wrote:
> On 08/11/18 08:08, Juergen Gross wrote:
>> On 07/11/2018 10:30, Sander Eikelenboom wrote:
>>> Hi Juergen / Boris,
>>>
>>> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
>>> branch pulled on top.
>>> Unfortunately i was s
On 07/11/2018 18:20, Andrew Cooper wrote:
> On 09/10/18 16:21, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they will eventually be scrubbed in idle-loop on every
>>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-i386-pvgrub
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.gi
>>> On 07.11.18 at 18:15, wrote:
> On Wed, Nov 07, 2018 at 08:06:00AM -0700, Jan Beulich wrote:
>> >>> On 07.11.18 at 12:11, wrote:
>> > On Mon, Nov 05, 2018 at 09:56:13AM -0700, Jan Beulich wrote:
>> >> >>> On 30.10.18 at 16:41, wrote:
>> >> > BAR map/unmap is a long running operation that need
.986248] cpu 2 spinlock event irq 65
[1.996200] installing Xen timer for CPU 3
[1.999522] #3
[2.082921] cpu 3 spinlock event irq 71
[2.092749] smp: Brought up 1 node, 4 CPUs
[2.096079] smpboot: Max logical packages: 1
[2.099410] smpboot: Total of 4 processors activated (256
>>> On 08.11.18 at 04:14, wrote:
> this #define is unnecessary since XSM_INLINE is redefined in
> xsm/dummy.h, it's a risk of build breakage, so remove it.
>
> Signed-off-by: Xin Li
> Reviewed-by: Jan Beulich
I'm confused - this and patches 2 and 3 went in already, didn't they?
And quite some
>>> On 07.11.18 at 18:52, wrote:
> On 10/31/2018 11:19 PM, Xin Li (Talons) wrote:
>> In patchset v4, we call register_xsm() to setup silo module.
>> This debug log is to check if some ops not overrided by the module.
>> I thought this is OK, since the log level is debug.
>>
>> I think calling reg
On 08/11/2018 10:05, Jan Beulich wrote:
On 07.11.18 at 18:52, wrote:
>> On 10/31/2018 11:19 PM, Xin Li (Talons) wrote:
>>> In patchset v4, we call register_xsm() to setup silo module.
>>> This debug log is to check if some ops not overrided by the module.
>>> I thought this is OK, since the l
>>> On 07.11.18 at 22:46, wrote:
> flight 129468 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/129468/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmres
On 08/11/2018 10:57, Sander Eikelenboom wrote:
> On 08/11/18 09:18, Juergen Gross wrote:
>> On 08/11/2018 09:14, Sander Eikelenboom wrote:
>>> On 08/11/18 08:08, Juergen Gross wrote:
On 07/11/2018 10:30, Sander Eikelenboom wrote:
> Hi Juergen / Boris,
>
> Last week i tested Linux k
On 07/11/2018 13:28, Wei Liu wrote:
> On Tue, Nov 06, 2018 at 12:07:58PM +, Sergey Dyasli wrote:
>> The size of Xen's virtual vmcs region is 4096 bytes (see comment about
>> Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
>> it to the guest in case when VMCS shadowing i
flight 75581 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75581/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 7
jobs:
build-amd64 pass
build-armhf
>>> On 07.11.18 at 19:20, wrote:
> On 09/10/18 16:21, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they will eventually be scrubbed in idle-loop on every
>> online
On 08/11/18 10:31, Jan Beulich wrote:
On 07.11.18 at 19:20, wrote:
>> On 09/10/18 16:21, Sergey Dyasli wrote:
>>> Scrubbing RAM during boot may take a long time on machines with lots
>>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>>> initially so they will eventually b
On Thu, Nov 08, 2018 at 02:55:56AM -0700, Jan Beulich wrote:
> >>> On 07.11.18 at 18:15, wrote:
> > On Wed, Nov 07, 2018 at 08:06:00AM -0700, Jan Beulich wrote:
> >> >>> On 07.11.18 at 12:11, wrote:
> >> > On Mon, Nov 05, 2018 at 09:56:13AM -0700, Jan Beulich wrote:
> >> >> >>> On 30.10.18 at 16:
Hi,
Sorry to jump in the conversation late.
On 11/8/18 11:29 AM, Roger Pau Monné wrote:
Why would that be? The do_softirq() invocation sits on the exit-
to-guest path, explicitly avoiding any such nesting unless there
was a do_softirq() invocation somewhere in a softirq handler.
It sits on an
On Thu, Nov 08, 2018 at 11:42:35AM +, Julien Grall wrote:
> Hi,
>
> Sorry to jump in the conversation late.
>
> On 11/8/18 11:29 AM, Roger Pau Monné wrote:
> > > Why would that be? The do_softirq() invocation sits on the exit-
> > > to-guest path, explicitly avoiding any such nesting unless t
Hi Roger,
On 11/8/18 11:44 AM, Roger Pau Monné wrote:
On Thu, Nov 08, 2018 at 11:42:35AM +, Julien Grall wrote:
Hi,
Sorry to jump in the conversation late.
On 11/8/18 11:29 AM, Roger Pau Monné wrote:
Why would that be? The do_softirq() invocation sits on the exit-
to-guest path, explicit
On 08/11/18 11:18, Juergen Gross wrote:
> On 08/11/2018 10:57, Sander Eikelenboom wrote:
>> On 08/11/18 09:18, Juergen Gross wrote:
>>> On 08/11/2018 09:14, Sander Eikelenboom wrote:
On 08/11/18 08:08, Juergen Gross wrote:
> On 07/11/2018 10:30, Sander Eikelenboom wrote:
>> Hi Juergen
On Thu, Nov 08, 2018 at 11:52:57AM +, Julien Grall wrote:
> Hi Roger,
>
> On 11/8/18 11:44 AM, Roger Pau Monné wrote:
> > On Thu, Nov 08, 2018 at 11:42:35AM +, Julien Grall wrote:
> > > Hi,
> > >
> > > Sorry to jump in the conversation late.
> > >
> > > On 11/8/18 11:29 AM, Roger Pau Mon
>>> On 08.11.18 at 12:29, wrote:
> On Thu, Nov 08, 2018 at 02:55:56AM -0700, Jan Beulich wrote:
>> >>> On 07.11.18 at 18:15, wrote:
>> > On Wed, Nov 07, 2018 at 08:06:00AM -0700, Jan Beulich wrote:
>> >> >>> On 07.11.18 at 12:11, wrote:
>> >> > On Mon, Nov 05, 2018 at 09:56:13AM -0700, Jan Beuli
On Wed, Nov 07, 2018 at 04:15:17PM +0100, Juergen Gross wrote:
> On 07/11/2018 16:06, Daniel Kiper wrote:
> > On Wed, Nov 07, 2018 at 11:49:38AM +0100, Daniel Kiper wrote:
> >> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote:
> >> On 02.11.18 at 18:59, wrote:
> It’s time again
Hi Roger,
On 11/8/18 12:20 PM, Roger Pau Monné wrote:
On Thu, Nov 08, 2018 at 11:52:57AM +, Julien Grall wrote:
Hi Roger,
On 11/8/18 11:44 AM, Roger Pau Monné wrote:
On Thu, Nov 08, 2018 at 11:42:35AM +, Julien Grall wrote:
Hi,
Sorry to jump in the conversation late.
On 11/8/18 11:
On Thu, Nov 08, 2018 at 05:32:02AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 12:29, wrote:
> > On Thu, Nov 08, 2018 at 02:55:56AM -0700, Jan Beulich wrote:
> >> >>> On 07.11.18 at 18:15, wrote:
> >> Then if the blocked bit is not set the call to do_softirq
> >> > would be recurred, thus pro
>>> On 08.11.18 at 13:47, wrote:
> My point would be that on x86 I think the only way to have preemptible
> long-running operations inside of Xen is to block the guest vCPU and
> run them in a tasklet, or at least this seems the less invasive one.
>
> Do you still have objections to this patch/ap
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced pro
On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 13:47, wrote:
> > My point would be that on x86 I think the only way to have preemptible
> > long-running operations inside of Xen is to block the guest vCPU and
> > run them in a tasklet, or at least this seems the
> -Original Message-
> From: Markus Armbruster [mailto:arm...@redhat.com]
> Sent: 05 November 2018 15:58
> To: Paul Durrant
> Cc: 'Kevin Wolf' ; Tim Smith ;
> Stefano Stabellini ; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Max Reitz ; Anthony Perard
> ; xen-devel@lists.xenproject.org
On Mon, 5 Nov 2018 02:40:28 +0100
Samuel Ortiz wrote:
> XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
> Description Table). RSDT only allow for 32-bit addressses and have thus
> been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and
> no longer RSDTs, although
On Mon, 5 Nov 2018 02:40:39 +0100
Samuel Ortiz wrote:
> From: Yang Zhong
>
> When using the generated memory hotplug AML, the iasl
> compiler would give the following error:
>
> dsdt.dsl 266: Return (MOST (_UID, Arg0, Arg1, Arg2))
> Error 6080 - Called method returns no value ^
>
> Signed-of
PV Dom0 has a quirk for some AMD processors, where enabling ACPI can
also enable C1E mode. Apply the same workaround as done on PV for a
PVH Dom0, which consist on trapping accesses to the SMI command IO
port and disabling C1E if ACPI is enabled.
Reported-by: Jan Beulich
Signed-off-by: Roger Pau
On Mon, 5 Nov 2018 02:40:26 +0100
Samuel Ortiz wrote:
> For both x86 and ARM architectures, the internal RSDP build API can
> return void as the current return value is unused.
>
> Signed-off-by: Samuel Ortiz
Reviewed-by: Igor Mammedov
> ---
> hw/arm/virt-acpi-build.c | 4 +---
> hw/i386/ac
Hi Igor,
On Thu, Nov 08, 2018 at 03:16:23PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:28 +0100
> Samuel Ortiz wrote:
>
> > XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
> > Description Table). RSDT only allow for 32-bit addressses and have thus
> > been deprecated
On Thu, Nov 08, 2018 at 03:23:58PM +0100, Roger Pau Monne wrote:
> PV Dom0 has a quirk for some AMD processors, where enabling ACPI can
> also enable C1E mode. Apply the same workaround as done on PV for a
> PVH Dom0, which consist on trapping accesses to the SMI command IO
> port and disabling C1E
>>> On 06.11.18 at 23:05, wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -99,6 +99,12 @@
> __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> (typeof(ptr)) (__ptr + (off)); })
>
> +/*
> + * Use RELOC_HIDE with symbols such as _stext and _etext to avoid e
(CCing Roger)
On 08/11/2018 11:07, Andrew Cooper wrote:
> On 08/11/18 10:31, Jan Beulich wrote:
> On 07.11.18 at 19:20, wrote:
>>> On 09/10/18 16:21, Sergey Dyasli wrote:
Scrubbing RAM during boot may take a long time on machines with lots
of RAM. Add 'idle' option to bootscrub whic
>>> On 06.11.18 at 23:05, wrote:
> Use SYMBOL everywhere _stext, _etext, etc. are used. Technically, it
> is required when comparing and subtracting pointers [1], but use it
> everywhere to avoid confusion.
I think using it when not needed is causing more confusion. Also
why would you then not us
On Thu, 8 Nov 2018 15:16:23 +0100
Igor Mammedov wrote:
[...]
> patch 4: convert arm's impl. to build_append_int_noprefix() API (commit
> 5d7a334f7)
>... move out to aml-build.c
my mistake, generally when we move something out,
we should do it in separate path preferably without an
On Thu, Nov 08, 2018 at 03:52:21PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 08, 2018 at 02:42:27PM +, Wei Liu wrote:
> > On Thu, Nov 08, 2018 at 03:23:58PM +0100, Roger Pau Monne wrote:
> > > PV Dom0 has a quirk for some AMD processors, where enabling ACPI can
> > > also enable C1E mode. App
>>> On 08.11.18 at 15:23, wrote:
> PV Dom0 has a quirk for some AMD processors, where enabling ACPI can
> also enable C1E mode. Apply the same workaround as done on PV for a
> PVH Dom0, which consist on trapping accesses to the SMI command IO
> port and disabling C1E if ACPI is enabled.
>
> Repor
Obviously it won't exist when PV is disabled.
Signed-off-by: Wei Liu
---
Based on Roger's "amd/pvh: enable ACPI C1E disable quirk on PVH Dom0".
This is the last patch needed to make CONFIG_PV work.
---
xen/arch/x86/cpu/amd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/cpu
On Thu, Nov 08, 2018 at 02:42:27PM +, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 03:23:58PM +0100, Roger Pau Monne wrote:
> > PV Dom0 has a quirk for some AMD processors, where enabling ACPI can
> > also enable C1E mode. Apply the same workaround as done on PV for a
> > PVH Dom0, which consist on
On 08/11/18 14:58, Wei Liu wrote:
> Obviously it won't exist when PV is disabled.
>
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
> On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
> wrote:
>>
>> This patch adds a couple of regs to the vm_event that are used by
>> the introspection. The base, limit and ar
>> bits are compressed into a uint64_t union so as not to enlarge the
>>
Am 08.11.2018 um 15:00 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Markus Armbruster [mailto:arm...@redhat.com]
> > Sent: 05 November 2018 15:58
> > To: Paul Durrant
> > Cc: 'Kevin Wolf' ; Tim Smith ;
> > Stefano Stabellini ; qemu-bl...@nongnu.org; qemu-
> > de...@nongnu
On Thu, Nov 08, 2018 at 02:48:40PM +, Sergey Dyasli wrote:
> (CCing Roger)
>
> On 08/11/2018 11:07, Andrew Cooper wrote:
> > On 08/11/18 10:31, Jan Beulich wrote:
> > On 07.11.18 at 19:20, wrote:
> >>> On 09/10/18 16:21, Sergey Dyasli wrote:
> Scrubbing RAM during boot may take a lon
On Thu, Nov 08, 2018 at 02:58:09PM +, Wei Liu wrote:
> Obviously it won't exist when PV is disabled.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> >>> On 05.11.18 at 16:49, wrote:
> > On 05/11/18 15:48, Wei Liu wrote:
> >> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> >> On 02.11.18 at 16:55, wrote:
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/a
>>> On 08.11.18 at 15:58, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -631,7 +631,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> case 0xf ... 0x17:
> disable_c1e(NULL);
> if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value
On Wed, Nov 07, 2018 at 03:49:51PM +0100, Juergen Gross wrote:
> On 07/11/2018 13:21, Daniel Kiper wrote:
> > On Fri, Nov 02, 2018 at 01:37:24PM +0100, Juergen Gross wrote:
> >> With Xen PVH mode adding a new machine type the machine related headers
> >> need to be present for the build to succeed.
On Thu, Nov 08, 2018 at 08:34:35AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 15:58, wrote:
> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x86/cpu/amd.c
> > @@ -631,7 +631,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> > case 0xf ... 0x17:
> > disable_c1e(NULL);
> >
>>> On 08.11.18 at 16:33, wrote:
> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
>> >>> On 05.11.18 at 16:49, wrote:
>> > On 05/11/18 15:48, Wei Liu wrote:
>> >> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
>> >> On 02.11.18 at 16:55, wrote:
>> --- a/xen/a
On 08/11/2018 16:36, Daniel Kiper wrote:
> On Wed, Nov 07, 2018 at 03:49:51PM +0100, Juergen Gross wrote:
>> On 07/11/2018 13:21, Daniel Kiper wrote:
>>> On Fri, Nov 02, 2018 at 01:37:24PM +0100, Juergen Gross wrote:
With Xen PVH mode adding a new machine type the machine related headers
On 08/11/18 15:33, Wei Liu wrote:
> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> On 05.11.18 at 16:49, wrote:
>>> On 05/11/18 15:48, Wei Liu wrote:
On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
On 02.11.18 at 16:55, wrote:
>> --- a/xen/arch/x
>>> On 08.11.18 at 16:38, wrote:
> On Thu, Nov 08, 2018 at 08:34:35AM -0700, Jan Beulich wrote:
>> >>> On 08.11.18 at 15:58, wrote:
>> > --- a/xen/arch/x86/cpu/amd.c
>> > +++ b/xen/arch/x86/cpu/amd.c
>> > @@ -631,7 +631,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>> >case 0xf ... 0x17:
>
On Fri, Nov 02, 2018 at 01:37:27PM +0100, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH. They will be filled
> with code later when the related functionality is being added.
>
> Signed-off-by: Juergen Gross
> ---
> V3: xenpvh->xen_pvh (Daniel Kiper)
> adjust copyright
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 08 November 2018 15:21
> To: Paul Durrant
> Cc: 'Markus Armbruster' ; Anthony Perard
> ; Tim Smith ; Stefano
> Stabellini ; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org; Max Reitz ; xen-
> de...@lists.xenproject.o
On Thu, Nov 08, 2018 at 08:39:36AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 16:33, wrote:
> > On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> >> >>> On 05.11.18 at 16:49, wrote:
> >> > On 05/11/18 15:48, Wei Liu wrote:
> >> >> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beu
>>> On 08.11.18 at 16:36, wrote:
> On 08/11/18 15:33, Wei Liu wrote:
>> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
>> On 05.11.18 at 16:49, wrote:
On 05/11/18 15:48, Wei Liu wrote:
> On Mon, Nov 05, 2018 at 08:04:37AM -0700, Jan Beulich wrote:
> On 02.11.18
On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
> On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
> > On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
> > wrote:
> >>
> >> This patch adds a couple of regs to the vm_event that are used by
> >> the introspection. The base, limit an
On Fri, Nov 02, 2018 at 01:37:28PM +0100, Juergen Gross wrote:
> Add the code for the Xen PVH mode boot entry.
>
> Signed-off-by: Juergen Gross
One nitpick below. Otherwise
Reviewed-by: Daniel Kiper
> ---
> V3: clear %fs and %gs, too (Daniel Kiper)
> use GRUB_MEMORY_MACHINE_PROT_STACK_SIZ
On 11/8/18 5:53 PM, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
>> On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
>>> On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
>>> wrote:
This patch adds a couple of regs to the vm_event that are used by
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific ha
flight 129514 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129514/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129405
test-armhf-armhf-libvirt 14 sav
We don't need bigger alignment except when calling EFI boot or runtime
services functions (and we don't guarantee that either, as explained
close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
declaration). Hence if the compiler supports reducing stack alignment
from the ABI comp
While we don't mean to run their objtool over our generated code, it
still seems desirable to avoid calls to further functions before a
function's frame pointer is set up.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v5: New.
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/st
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent pat
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls, makin
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
Reviewe
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: Andrew Cooper
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -185,7 +185,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_maskin
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(
On Thu, Nov 08, 2018 at 08:49:44AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 16:36, wrote:
> > On 08/11/18 15:33, Wei Liu wrote:
> >> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
> >> On 05.11.18 at 16:49, wrote:
> On 05/11/18 15:48, Wei Liu wrote:
> > On Mon, No
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Reviewed-by: Andre
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target
In preparation of allowing inline functions in asm/iommu.h to
de-reference struct struct iommu_ops, move the inclusion downwards past
the declaration of that structure. This in turn requires moving the
struct domain_iommu declaration, as it requires struct arch_iommu to be
fully declared beforehand
There's no need to go through an extra level of indirection. In order to
limit code churn, call sites using struct domain_iommu's platform_ops
don't get touched here, however.
Signed-off-by: Jan Beulich
---
v5: Re-base over dropped IOMMU_MIXED patch.
v4: New.
--- a/xen/drivers/passthrough/amd/pc
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, unless perhaps sitting on an error path
next to a call which gets changed (in which case I think the error
path better remains consistent with the respective main path).
Signed-off-by: Jan Beulich
--
>>> On 08.11.18 at 17:09, wrote:
> On Thu, Nov 08, 2018 at 08:49:44AM -0700, Jan Beulich wrote:
>> >>> On 08.11.18 at 16:36, wrote:
>> > On 08/11/18 15:33, Wei Liu wrote:
>> >> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beulich wrote:
>> >> On 05.11.18 at 16:49, wrote:
>> On 05/11/18
>>> On 08.11.18 at 14:20, wrote:
> On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
>> >>> On 08.11.18 at 13:47, wrote:
>> > My point would be that on x86 I think the only way to have preemptible
>> > long-running operations inside of Xen is to block the guest vCPU and
>> > run them i
On Thu, Nov 08, 2018 at 09:22:08AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 17:09, wrote:
> > On Thu, Nov 08, 2018 at 08:49:44AM -0700, Jan Beulich wrote:
> >> >>> On 08.11.18 at 16:36, wrote:
> >> > On 08/11/18 15:33, Wei Liu wrote:
> >> >> On Mon, Nov 05, 2018 at 09:11:44AM -0700, Jan Beu
On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> The new ept_set_ad_sync() function has been added to upda
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 08 November 2018 15:44
> To: 'Kevin Wolf'
> Cc: Stefano Stabellini ; qemu-bl...@nongnu.org;
> Tim Smith ; qemu-de...@nongnu.org; 'Markus
> Armbruster' ; Anthony Perard
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
tools/xenstore/include/xenstore.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstore/include/xenstore.h
b/tools/xenstore/include/xenstore.h
index 064b62c455..889dc23863 100644
--- a/tools/xenstore/include/xenstore.
This is an integer type, not a pointer.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
tools/libvchan/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index ba5a6eb29e..180833dc2f 100644
--- a/tools/libvchan/init.c
+++ b/
On 11/8/18 6:56 PM, George Dunlap wrote:
> On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
>> This patch is a pre-requisite for fixing the logdirty VGA issue
>> (display freezes when switching to a new altp2m view early in a
>> domain's lifetime), but sent separately for easier review.
>> The new ep
Delete 11 entirely formulaic conditional calls to
xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
and associated logger_tofree variables, error handling, etc.
No overall functional change, although some memory allocation errors
may no longer occur.
After this there are still several call
No functional change.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/init.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
ind
The point of this series is to make an API promise about what ENOENT
means from libxenvchan_client_init, to make it easier to build async
code on top of this (eg, libxl).
There is a lot of internal tidying, but also a necessary prefix is a
change to xentoollog to make it OK to pass NULL for a logg
These functions do in fact leave errno set. We are going to want to
use this.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/libxenvchan.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libvchan/libxenvchan.h b/too
Previously xtl_log, xtl_logv and xtl_progress would all crash if
passed logger=NULL. Have the use the default logger instead.
This is more convenient.
Signed-off-by: Ian Jackson
CC: Wei Liu
---
v2: New in this version of the series
---
tools/libs/toollog/include/xentoollog.h | 9 +
too
* Abolish fail_xs_open which is now exactly the same as fail.
* Change all gotos to refer to fail instead.
No functional change.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/init.c | 13 ++---
1 file changed, 6 insertions(+), 7 deleti
We are going to add a call to xtl_log.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/libvchan/Makefile | 6 +++---
tools/libvchan/xenvchan.pc.in | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libvchan/Makefile b/tools/
And place it into .text.cold.
Requested-by: Jan Beulich
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/traps.c | 20 +---
xen/include/xen/init.h | 1 +
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.
* Promise that we will set errno to ENOENT if the server is not
yet set up.
* Arrange that all ENOENT returns other than from the read of ring-ref
are turned into EIO, logging when we do so.
Signed-off-by: Ian Jackson
CC: Marek Marczykowski-Górecki
---
tools/libvchan/init.c| 11
This is most conveniently done like this because xtl_logger_stdio.c
knows how to provide a static logger without doing any memory
allocations. That's useful because it can't fail.
Add the new symbol to the map file and bump the minor version
accordingly.
Signed-off-by: Ian Jackson
CC: Wei Liu
* Use xs_close instead of the deprecated xs_daemon_close.
* Initialise xs to NULL.That means xs_close can now be called in
all cases. Move it to the fail clause.
* free(domid_str) is already safe in all cases since domid_str is
initialised to NULL. Move it to the fail clause.
No overal
On Thu, Nov 08, 2018 at 09:25:26AM -0700, Jan Beulich wrote:
> >>> On 08.11.18 at 14:20, wrote:
> > On Thu, Nov 08, 2018 at 06:04:11AM -0700, Jan Beulich wrote:
> >> >>> On 08.11.18 at 13:47, wrote:
> >> > My point would be that on x86 I think the only way to have preemptible
> >> > long-running
On Thu, Nov 08, 2018 at 05:56:07PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 5:53 PM, Wei Liu wrote:
> > On Thu, Nov 08, 2018 at 05:19:48PM +0200, Razvan Cojocaru wrote:
> >> On 11/6/18 7:16 PM, Tamas K Lengyel wrote:
> >>> On Mon, Nov 5, 2018 at 2:54 AM Alexandru Stefan ISAILA
> >>> wrote:
> >>>
1 - 100 of 150 matches
Mail list logo
