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
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
>>> 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
>>> 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
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
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
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 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
>>> 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
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
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
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
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
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
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,
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
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
> -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
> ;
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
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
>>> 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:
>
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
>>> 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
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
pu 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 (25688.36 Bogo
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
>>> 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 |
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
> -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-
>
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
>>> 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 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,
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 ^
>
>
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 +---
>
>>> 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
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-
> >
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
> +++
>>> 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:
>> ---
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 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:
>> ---
>>> 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.
>
>
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
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 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
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
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
>>> 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
(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
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.
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
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
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
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
0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
truth table for what `xl info` would report. In order to make the
table work xen will need to report its PV capability.
Replace cap_directio with cap_pv in libxl IDL. It is safe to do so
because cap_directio has never been
On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
I will commit these two patches without acks. They are a net benefit to
Xen -- I don't think that will be controversial.
Wei.
___
Xen-devel mailing list
Hi,
On 11/7/18 7:01 PM, Stefano Stabellini wrote:
On Wed, 7 Nov 2018, Julien Grall wrote:
On 07/11/2018 12:18, Julien Grall wrote:
Hi Stefano,
On 07/11/2018 00:32, Stefano Stabellini wrote:
On Mon, 22 Oct 2018, Julien Grall wrote:
Hi,
On 09/10/2018 00:37, Stefano Stabellini wrote:
flight 129650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129650/
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
On 08/11/18 18:09, Wei Liu wrote:
> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
>> Signed-off-by: Wei Liu
> I will commit these two patches without acks. They are a net benefit to
> Xen -- I don't think that will be controversial.
LGTM. Acked-by: Andrew Cooper
On Thu, Nov 08, 2018 at 06:29:05PM +, Andrew Cooper wrote:
> On 08/11/18 18:08, Wei Liu wrote:
> > 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
> > truth table for what `xl info` would report. In order to make the
> > table work xen will need to report its PV capability.
>
On Thu, Nov 08, 2018 at 06:13:23PM +, Andrew Cooper wrote:
> On 08/11/18 18:09, Wei Liu wrote:
> > On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
> >> Signed-off-by: Wei Liu
> > I will commit these two patches without acks. They are a net benefit to
> > Xen -- I don't think that
> On Nov 8, 2018, at 12:09 PM, Wei Liu wrote:
>
>> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
>> Signed-off-by: Wei Liu
>
> I will commit these two patches without acks. They are a net benefit to
> Xen -- I don't think that will be controversial.
>
> Wei.
Sounds good to me.
flight 129604 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129604/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty VGA: it
On 11/8/18 8:02 PM, Wei Liu wrote:
> Speaking of build breakage: would you guys consider signing up to gitlab
> so that you can use all the build test infrastructure there before
> submission? It would probably say you from building local for different
> distros and configs.
>
> See
On 08/11/18 18:30, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 06:29:05PM +, Andrew Cooper wrote:
>> On 08/11/18 18:08, Wei Liu wrote:
>>> 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
>>> truth table for what `xl info` would report. In order to make the
>>> table work xen
On Thu, Nov 08, 2018 at 07:56:29PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 7:22 PM, Wei Liu wrote:
> > 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
On 11/8/18 8:27 PM, Wei Liu wrote:
> On Thu, Nov 08, 2018 at 08:22:06PM +0200, Razvan Cojocaru wrote:
>> On 11/8/18 8:02 PM, Wei Liu wrote:
>>> Speaking of build breakage: would you guys consider signing up to gitlab
>>> so that you can use all the build test infrastructure there before
>>>
On 08/11/18 18:08, Wei Liu wrote:
> 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
> truth table for what `xl info` would report. In order to make the
> table work xen will need to report its PV capability.
>
> Replace cap_directio with cap_pv in libxl IDL. It is safe to do so
>
On Thu, Nov 08, 2018 at 12:27:40PM -0600, Doug Goldstein wrote:
>
> > On Nov 8, 2018, at 12:09 PM, Wei Liu wrote:
> >
> >> On Mon, Oct 22, 2018 at 04:18:51PM +0100, Wei Liu wrote:
> >> Signed-off-by: Wei Liu
> >
> > I will commit these two patches without acks. They are a net benefit to
> >
On 11/8/18 8:14 PM, George Dunlap wrote:
> On 11/01/2018 02:45 PM, Razvan Cojocaru wrote:
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The reason is the way
>> Xen
> From: Xin Li
>
> Filling dummy module's hook to null value of xsm_operations structure
> will generate debug message. This becomes boot time spew for module
> like silo, which only sets a few hooks of itself. So remove the printing
> to avoid boot time spew.
>
> Signed-off-by: Xin Li
On Thu, Nov 08, 2018 at 08:46:12PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 8:27 PM, Wei Liu wrote:
> > On Thu, Nov 08, 2018 at 08:22:06PM +0200, Razvan Cojocaru wrote:
> >> On 11/8/18 8:02 PM, Wei Liu wrote:
> >>> Speaking of build breakage: would you guys consider signing up to gitlab
> >>> so
On Thu, Nov 08, 2018 at 08:22:06PM +0200, Razvan Cojocaru wrote:
> On 11/8/18 8:02 PM, Wei Liu wrote:
> > Speaking of build breakage: would you guys consider signing up to gitlab
> > so that you can use all the build test infrastructure there before
> > submission? It would probably say you from
On 08/11/2018 16:45, Daniel Kiper wrote:
> 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:
On Thu, 8 Nov 2018, Jan Beulich wrote:
> >>> 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
On Thu, 8 Nov 2018, Jan Beulich wrote:
> >>> 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
flight 129656 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129656/
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
If a hot-attaching device fails inside domU[ex:negotiate_mq() returns
with ENOMEM] we clear the blkfront_info struct in talk_to_blkback()
When we try to detach the device, blkfront_remove() tries to access
blkfront_info leading to kernel panic.
Typical call stack involving panic -
#10
When we try to detach the device, blkfront_remove() tries to access
blkfront_info leading to kernel panic.
Typical call stack involving panic -
#10 page_fault at 816f25df
[exception RIP: blkif_free+46]
#11 blkfront_remove at a004de47 [xen_blkfront]
#12 xenbus_dev_remove at
flight 129662 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 129532 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129532/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw broken
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
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
flight 129678 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129678/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 129530 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
125898
This run is configured for baseline tests only.
flight 75582 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 11 guest-start
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
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
flight 129682 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On 08/11/18 17:31, Andrew Cooper wrote:
> On 08/11/18 17:28, Ian Jackson wrote:
>> Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 01/11] tools/libs/toollog:
>> Provide a default logger"):
>>> You want something like:
>>>
>>> static xentoollog_logger_stdiostream stdio_logger = {
>>> .vtable
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
---
xen/arch/x86/pv/dom0_build.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 21d262b..812b026 100644
---
On 11/8/18 7:22 PM, Wei Liu wrote:
> 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
On Thu, Nov 08, 2018 at 05:46:51PM +, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 129686 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
>>> On 08.11.18 at 23:27, wrote:
> On Thu, 8 Nov 2018, Jan Beulich wrote:
>> >>> On 06.11.18 at 23:05, wrote:
>> > ---
>> > xen/arch/arm/alternative.c | 7 ++--
>> > xen/arch/arm/arm32/livepatch.c | 2 +-
>> > xen/arch/arm/arm64/livepatch.c | 2 +-
>> >
On 09/11/2018 07:53, Jacob Wen wrote:
> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY is already able to make sure backend sees
> requests before req_prod is updated.
>
> Signed-off-by: Jacob Wen
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY is already able to make sure backend sees
requests before req_prod is updated.
Signed-off-by: Jacob Wen
---
drivers/net/xen-netfront.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index
1 - 100 of 148 matches
Mail list logo
