On 6/23/20 4:20 AM, Stefano Stabellini wrote:
> On Mon, 22 Jun 2020, Julien Grall wrote:
> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it
> via
>
> CFLAGS or something. This can also be done for the location of Xen
> headers.
__XEN_INTERFACE_VERSI
flight 151288 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 16 guest-localmigrate fail REGR. vs. 151232
test-amd64-i386-libvi
On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland
wrote:
>
> On 22/06/2020 21:33, Jason Andryuk wrote:
>
> > Hi,
> >
> > Running qemu devel for a Xen VM is failing an assert after the recent
> > "qdev: Rework how we plug into the parent bus" sysbus changes.
> >
> > qemu-system-i386: hw/core/qdev.c:
> +rc = xenforeignmemory_unmap_resource(fmem, fres);
> +
> +if (rc) {
> +fprintf(stderr, "Failed to unmap resource\n");
> +return 1;
> +}
> +
> +rc = xc_vmtrace_pt_disable(xc, domid, vcpu_id);
> +
> +if (rc) {
> +fprintf(stderr, "Failed to call xc_vmtrace
Hi Stefano,
Stefano Stabellini writes:
> On Fri, 19 Jun 2020, Volodymyr Babchuk wrote:
>> Trusted Applications use popular approach to determine required size
>> of buffer: client provides a memory reference with the NULL pointer to
>> a buffer. This is so called "Null memory reference". TA upd
flight 151286 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065
test-amd64-i386-l
On Mon, 22 Jun 2020, Julien Grall wrote:
> > > > For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it
> > > > via
> > > >
> > > > CFLAGS or something. This can also be done for the location of Xen
> > > > headers.
> > >
> > > __XEN_INTERFACE_VERSION__ should work through the C
On Fri, 19 Jun 2020, Volodymyr Babchuk wrote:
> Normal World can share buffer with OP-TEE for two reasons:
> 1. Some client application wants to exchange data with TA
> 2. OP-TEE asks for shared buffer for internal needs
>
> The second case was handle more strictly than necessary:
>
> 1. In RPC r
On Fri, 19 Jun 2020, Volodymyr Babchuk wrote:
> Trusted Applications use popular approach to determine required size
> of buffer: client provides a memory reference with the NULL pointer to
> a buffer. This is so called "Null memory reference". TA updates the
> reference with the required size and
- 22 cze 2020 o 18:16, Jan Beulich jbeul...@suse.com napisał(a):
> On 22.06.2020 18:02, Michał Leszczyński wrote:
>> - 22 cze 2020 o 17:22, Jan Beulich jbeul...@suse.com napisał(a):
>>> On 22.06.2020 16:35, Michał Leszczyński wrote:
- 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse
flight 151283 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 151214
Regressions which a
On 22/06/2020 21:33, Jason Andryuk wrote:
> Hi,
>
> Running qemu devel for a Xen VM is failing an assert after the recent
> "qdev: Rework how we plug into the parent bus" sysbus changes.
>
> qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion
> `dc->bus_type && object_dynamic_ca
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.or
Hi,
Running qemu devel for a Xen VM is failing an assert after the recent
"qdev: Rework how we plug into the parent bus" sysbus changes.
qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion
`dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)'
failed.
dc->bus_type is "
On 6/22/20 3:28 PM, Souptick Joarder wrote:
> On Tue, Jun 23, 2020 at 12:40 AM Boris Ostrovsky
> wrote:
>> On 6/22/20 2:52 PM, Souptick Joarder wrote:
>>> I read the code again. I think, this check is needed to handle a scenario
>>> when
>>> lock_pages() return -ENOSPC. Better to keep this check.
On Tue, Jun 23, 2020 at 12:40 AM Boris Ostrovsky
wrote:
>
> On 6/22/20 2:52 PM, Souptick Joarder wrote:
> >
> > I read the code again. I think, this check is needed to handle a scenario
> > when
> > lock_pages() return -ENOSPC. Better to keep this check. Let me post v2 of
> > this
> > RFC for a
On 6/22/20 2:52 PM, Souptick Joarder wrote:
>
> I read the code again. I think, this check is needed to handle a scenario when
> lock_pages() return -ENOSPC. Better to keep this check. Let me post v2 of this
> RFC for a clear view.
Actually, error handling seems to be somewhat broken here. If
loc
On Fri, Jun 19, 2020 at 1:00 PM John Hubbard wrote:
>
> On 2020-06-18 20:12, Souptick Joarder wrote:
> > On Wed, Jun 17, 2020 at 11:29 PM Boris Ostrovsky
> > wrote:
> >>
> >> On 6/16/20 11:14 PM, Souptick Joarder wrote:
> >>> In 2019, we introduced pin_user_pages*() and now we are converting
> >>
- 22 cze 2020 o 20:06, Michał Leszczyński michal.leszczyn...@cert.pl
napisał(a):
> This patch series implements an interface that Dom0 could use in order to
> enable IPT for particular vCPUs in DomU, allowing for external monitoring.
> Such
> a feature has numerous applications like malware
Add an demonstration tool that uses xc_vmtrace_* calls in order
to manage external IPT monitoring for DomU.
Signed-off-by: Michal Leszczynski
---
tools/proctrace/COPYING | 339
tools/proctrace/Makefile| 50 ++
tools/proctrace/proctrace.c | 158 ++
Allow to specify the size of per-vCPU trace buffer upon
domain creation. This is zero by default (meaning: not enabled).
Signed-off-by: Michal Leszczynski
---
docs/man/xl.cfg.5.pod.in | 10 ++
tools/golang/xenlight/helpers.gen.go | 2 ++
tools/golang/xenlight/types.gen.go
Add functions in libxc that use the new HVMOP_vmtrace interface.
Signed-off-by: Michal Leszczynski
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xenctrl.h | 39 +++
tools/libxc/xc_vmtrace.c | 94 +++
3 files changed, 134 insertions
Provide an interface for privileged domains to manage
external IPT monitoring. Guest IPT state will be preserved
across vmentry/vmexit using ipt_state structure.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/hvm.c | 168 +
xen/arch/x86/hvm/vmx/vmx
Check if Intel Processor Trace feature is supported by current
processor. Define hvm_ipt_supported function.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmcs.c | 7 ++-
xen/include/asm-x86/cpufeature.h| 1 +
xen/include/asm-x86/hvm/hvm.h
Define constants related to Intel Processor Trace features.
Signed-off-by: Michal Leszczynski
---
xen/include/asm-x86/msr-index.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index b328a47
Allow to acquire large resources by allowing acquire_resource()
to process items in batches, using hypercall continuation.
Signed-off-by: Michal Leszczynski
---
xen/common/memory.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/xen/common/me
Intel Processor Trace is an architectural extension available in modern Intel
family CPUs. It allows recording the detailed trace of activity while the
processor executes the code. One might use the recorded trace to reconstruct
the code flow. It means, to find out the executed code paths, deter
On 22/06/2020 15:33, Oleksandr Andrushchenko wrote:
On 6/22/20 5:27 PM, Julien Grall wrote:
Hi Oleksandr,
On 22/06/2020 15:04, Oleksandr Andrushchenko wrote:
On 6/19/20 11:02 PM, Stefano Stabellini wrote:
On Thu, 18 Jun 2020, Julien Grall wrote:
ifeq ($(CONFIG_XEN),y)
arch-y += -D__XEN_I
On 19/06/2020 14:39, Jan Beulich wrote:
> On 19.06.2020 15:28, Andrew Cooper wrote:
>> On 19/06/2020 13:48, Jan Beulich wrote:
>>> On 19.06.2020 13:58, Andrew Cooper wrote:
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t
> +struct xen_hvm_vmtrace_op {
> +/* IN variable */
> +uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */
> +uint32_t cmd;
> +/* Enable/disable external vmtrace for given domain */
> +#define HVMOP_vmtrace_ipt_enable 1
> +#define HVMOP_vmtrace_ipt
flight 151279 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-build fail in 151260 REGR. vs. 150040
build-i386-pre
On Mon, Jun 22, 2020 at 06:20:34PM +0200, Jan Beulich wrote:
> On 22.06.2020 18:09, Roger Pau Monné wrote:
> > On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote:
> >> On 2020-06-22 15:58, Roger Pau Monné wrote:
> >>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
>
- 22 cze 2020 o 18:25, Roger Pau Monné roger@citrix.com napisał(a):
> On Mon, Jun 22, 2020 at 06:16:57PM +0200, Jan Beulich wrote:
>> On 22.06.2020 18:02, Michał Leszczyński wrote:
>> > - 22 cze 2020 o 17:22, Jan Beulich jbeul...@suse.com napisał(a):
>> >> On 22.06.2020 16:35, Michał L
On 2020-06-22 18:20, Jan Beulich wrote:
On 22.06.2020 18:09, Roger Pau Monné wrote:
On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote:
On 2020-06-22 15:58, Roger Pau Monné wrote:
On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
Aha! Thank you for pointing this out. I
On Mon, Jun 22, 2020 at 06:16:57PM +0200, Jan Beulich wrote:
> On 22.06.2020 18:02, Michał Leszczyński wrote:
> > - 22 cze 2020 o 17:22, Jan Beulich jbeul...@suse.com napisał(a):
> >> On 22.06.2020 16:35, Michał Leszczyński wrote:
> >>> - 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse.com n
- 22 cze 2020 o 18:16, Jan Beulich jbeul...@suse.com napisał(a):
> On 22.06.2020 18:02, Michał Leszczyński wrote:
>> - 22 cze 2020 o 17:22, Jan Beulich jbeul...@suse.com napisał(a):
>>> On 22.06.2020 16:35, Michał Leszczyński wrote:
- 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse
On 22.06.2020 18:09, Roger Pau Monné wrote:
> On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote:
>> On 2020-06-22 15:58, Roger Pau Monné wrote:
>>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
Aha! Thank you for pointing this out. I think you may be right, but
>>>
On 22.06.2020 18:02, Michał Leszczyński wrote:
> - 22 cze 2020 o 17:22, Jan Beulich jbeul...@suse.com napisał(a):
>> On 22.06.2020 16:35, Michał Leszczyński wrote:
>>> - 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse.com napisał(a):
Is any of what you do in this switch() actually legit
On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote:
> On 2020-06-22 15:58, Roger Pau Monné wrote:
> > On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
> > > Aha! Thank you for pointing this out. I think you may be right, but
> > > this
> > > should be possible without doing
- 22 cze 2020 o 17:22, Jan Beulich jbeul...@suse.com napisał(a):
> On 22.06.2020 16:35, Michał Leszczyński wrote:
>> - 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse.com napisał(a):
>>> On 19.06.2020 01:41, Michał Leszczyński wrote:
+
+domain_pause(d);
>>>
>>> Who's the inten
On 22.06.2020 17:31, Martin Lucina wrote:
> On 2020-06-22 15:58, Roger Pau Monné wrote:
>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
>>> How about this arrangement, which appears to work for me; no hangs I
>>> can see
>>> so far and domU survives ping -f fine with no packet lo
On 22.06.2020 16:56, Roger Pau Monné wrote:
> On Mon, Jun 22, 2020 at 03:51:24PM +0200, Jan Beulich wrote:
>> On 22.06.2020 15:24, Roger Pau Monné wrote:
>>> On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote:
On 22.06.2020 11:31, Roger Pau Monné wrote:
> On Fri, Jun 19, 2020 at 0
On 2020-06-22 15:58, Roger Pau Monné wrote:
On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
Aha! Thank you for pointing this out. I think you may be right, but
this
should be possible without doing the demuxing in interrupt context.
If you don't do the demuxing in the interrupt
On 22.06.2020 16:35, Michał Leszczyński wrote:
> - 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse.com napisał(a):
>> On 19.06.2020 01:41, Michał Leszczyński wrote:
>>> +
>>> +domain_pause(d);
>>
>> Who's the intended caller of this interface? You making it a hvm-op
>> suggests the guest may
Hi all,
Xen 4.14 RC3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.14.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.14.0-rc3/xen-4.14.0-rc3.tar.gz
And the signature is at:
https://downloads.xenproject.org/
On Mon, Jun 22, 2020 at 03:51:24PM +0200, Jan Beulich wrote:
> On 22.06.2020 15:24, Roger Pau Monné wrote:
> > On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote:
> >> On 22.06.2020 11:31, Roger Pau Monné wrote:
> >>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote:
> On 1
- 22 cze 2020 o 15:25, Jan Beulich jbeul...@suse.com napisał(a):
> On 19.06.2020 01:41, Michał Leszczyński wrote:
>> +
>> +domain_pause(d);
>
> Who's the intended caller of this interface? You making it a hvm-op
> suggests the guest may itself call this. But of course a guest
> can't paus
On 6/22/20 5:27 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 22/06/2020 15:04, Oleksandr Andrushchenko wrote:
>> On 6/19/20 11:02 PM, Stefano Stabellini wrote:
>>> On Thu, 18 Jun 2020, Julien Grall wrote:
>> ifeq ($(CONFIG_XEN),y)
>> arch-y += -D__XEN_INTERFACE_VERSION__=0x00040d00
>> endif
>>
>
Hi Oleksandr,
On 22/06/2020 15:04, Oleksandr Andrushchenko wrote:
On 6/19/20 11:02 PM, Stefano Stabellini wrote:
On Thu, 18 Jun 2020, Julien Grall wrote:
ifeq ($(CONFIG_XEN),y)
arch-y += -D__XEN_INTERFACE_VERSION__=0x00040d00
endif
and we also have Xen 4.13 headers in the U-boot tree.
Sorry
On 22/06/2020 14:56, Oleksandr Andrushchenko wrote:
On 6/19/20 4:29 PM, Oleksandr Andrushchenko wrote:
On 6/19/20 4:15 PM, Julien Grall wrote:
On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko w
On 6/19/20 11:02 PM, Stefano Stabellini wrote:
> On Thu, 18 Jun 2020, Julien Grall wrote:
>>> Copy/pasting here from my comment on the pull request plus additional
>>> thoughts.
>>>
>>> Uboot is one of those embedded projects that typically assumes that all
>>> the information about the platform i
On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
> On 2020-06-19 19:42, Roger Pau Monné wrote:
> > On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote:
> > > On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote:
> > > > On 2020-06-19 13:21, Roger Pau Monné wrote:
On 22/06/2020 14:37, Jan Beulich wrote:
> On 22.06.2020 14:39, Andrew Cooper wrote:
>> On 22/06/2020 13:09, Jan Beulich wrote:
>>> Coverity validly complains that the new call from
>>> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
>>> two fields uninitialized, yet they get th
On 6/19/20 4:29 PM, Oleksandr Andrushchenko wrote:
> On 6/19/20 4:15 PM, Julien Grall wrote:
>>
>>
>> On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
>>>
>>> On 6/19/20 3:59 PM, Julien Grall wrote:
Hi,
On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
> On 6/19/20 3:47 PM,
On 22.06.2020 15:24, Roger Pau Monné wrote:
> On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote:
>> On 22.06.2020 11:31, Roger Pau Monné wrote:
>>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote:
On 18.06.2020 18:04, Roger Pau Monne wrote:
> Commit e9aca9470ed86 intr
On 22.06.2020 14:39, Andrew Cooper wrote:
> On 22/06/2020 13:09, Jan Beulich wrote:
>> Coverity validly complains that the new call from
>> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
>> two fields uninitialized, yet they get then consumed by
>> x86_cpuid_copy_to_buffer().
On 19.06.2020 01:41, Michał Leszczyński wrote:
> @@ -1631,6 +1649,8 @@ void hvm_vcpu_destroy(struct vcpu *v)
> vlapic_destroy(v);
>
> hvm_vcpu_cacheattr_destroy(v);
> +
> +hvm_vmtrace_destroy(v);
> }
Whenever possible resource cleanup should occur from
hvm_domain_relinquish_resour
On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote:
> On 22.06.2020 11:31, Roger Pau Monné wrote:
> > On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote:
> >> On 18.06.2020 18:04, Roger Pau Monne wrote:
> >>> Commit e9aca9470ed86 introduced a regression when avoiding sending
> >>>
flight 151276 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 150176
build-amd64-pr
On 19.06.2020 01:40, Michał Leszczyński wrote:
> @@ -630,6 +633,12 @@ static inline bool hvm_altp2m_supported(void)
> return hvm_funcs.altp2m_supported;
> }
>
> +/* returns true if hardware supports Intel Processor Trace */
> +static inline bool hvm_pt_supported(void)
> +{
> +return hvm
On 22/06/2020 13:09, Jan Beulich wrote:
> Coverity validly complains that the new call from
> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
> two fields uninitialized, yet they get then consumed by
> x86_cpuid_copy_to_buffer(). (All other present callers of the function
> pas
On 19.06.2020 01:39, Michał Leszczyński wrote:
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -621,4 +621,41 @@
> #define MSR_PKGC9_IRTL 0x0634
> #define MSR_PKGC10_IRTL 0x0635
>
> +/* Intel PT MSRs */
> +#
Coverity validly complains that the new call from
tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
two fields uninitialized, yet they get then consumed by
x86_cpuid_copy_to_buffer(). (All other present callers of the function
pass a pointer to a static - and hence initialized -
On 22.01.2020 02:59, Bobby Eshleman wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/sysctl.c
> @@ -0,0 +1,31 @@
> +/**
> + * Arch-specific sysctl.c
> + *
> + * System management operations. For use by node control stack.
> +
On 22.01.2020 02:58, Bobby Eshleman wrote:
> From: Alistair Francis
>
> Add the lib directory with find_next_bit support.
>
> This was taken from Linux
As was Arm64's - the two definitely would want folding.
Jan
On 22.06.2020 11:31, Roger Pau Monné wrote:
> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote:
>> On 18.06.2020 18:04, Roger Pau Monne wrote:
>>> Commit e9aca9470ed86 introduced a regression when avoiding sending
>>> IPIs for certain flush operations. Xen page fault handler
>>> (spuriou
On 2020-06-19 19:42, Roger Pau Monné wrote:
On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote:
On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote:
> On 2020-06-19 13:21, Roger Pau Monné wrote:
> > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
> > > On 20
On 22.06.2020 10:54, Roger Pau Monné wrote:
> On Fri, Jun 19, 2020 at 10:00:16PM +, Grzegorz Uriasz wrote:
>> @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct
>> acpi_table_header *table)
>> */
>> if (!pmtmr_ioport) {
>> pmtmr_ioport = fadt->pm_timer_block;
flight 151273 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151273/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 151245 pass in
151273
test-amd64-i386-xl-qemut-debi
On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote:
> On 18.06.2020 18:04, Roger Pau Monne wrote:
> > Commit e9aca9470ed86 introduced a regression when avoiding sending
> > IPIs for certain flush operations. Xen page fault handler
> > (spurious_page_fault) relies on blocking interrupts in
On Fri, Jun 12, Ian Jackson wrote:
> These files are in tree so that people can build (including from git)
> without needing recent autotools.
Do you know those people who can not possibly install the required (now 8year
old) autoconf version?
Olaf
signature.asc
Description: PGP signature
On Mon, Jun 22, 2020 at 10:54:00AM +0200, Roger Pau Monné wrote:
> On Fri, Jun 19, 2020 at 10:00:16PM +, Grzegorz Uriasz wrote:
> > On some computers the bit width of the PM Timer as reported
> > by ACPI is 32 bits when in fact the FADT flags report correctly
> > that the timer is 24 bits wide.
On Fri, Jun 19, 2020 at 10:00:16PM +, Grzegorz Uriasz wrote:
> On some computers the bit width of the PM Timer as reported
> by ACPI is 32 bits when in fact the FADT flags report correctly
> that the timer is 24 bits wide. On affected machines such as the
> ASUS FX504GM and never gaming laptops
On 20.06.2020 00:00, Grzegorz Uriasz wrote:
> @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct
> acpi_table_header *table)
>*/
> if (!pmtmr_ioport) {
> pmtmr_ioport = fadt->pm_timer_block;
> - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0;
>
On Fri, Jun 19, 2020 at 11:43:12PM +, Anchal Agarwal wrote:
> On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monné wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the con
On 22.06.2020 04:56, Michał Leszczyński wrote:
> - 19 cze 2020 o 1:41, Michał Leszczyński michal.leszczyn...@cert.pl
> napisał(a):
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -508,11 +508,25 @@ static void vmx_restore_host_msrs(void)
>>
>> static void vmx_save
On 22.06.2020 04:49, Michał Leszczyński wrote:
> - 19 cze 2020 o 15:44, Roger Pau Monné roger@citrix.com napisał(a):
>
>> On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote:
>>> Check if Intel Processor Trace feature is supported by current
>>> processor. Define hvm_ipt_sup
On 19.06.2020 20:23, Grzegorz Uriasz wrote:
> On 19/06/2020 15:17, Jan Beulich wrote:
>> On 19.06.2020 06:28, Grzegorz Uriasz wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -457,16 +457,16 @@ static u64 read_pmtimer_count(void)
>>> static s64 __init init_pmtimer(struct p
78 matches
Mail list logo
