>>> On 04.06.19 at 18:22, wrote:
> On 6/4/19 5:14 PM, Jan Beulich wrote:
> On 03.06.19 at 18:03, wrote:
>>> This patch introduces a config option HAS_M2P to tell whether an
>>> architecture implements the M2P.
>>> - iommu_hwdom_init: For now, we require the M2P support when the IOMMU
>>>
>>> On 04.06.19 at 18:23, wrote:
> On 6/4/19 5:21 PM, Jan Beulich wrote:
> On 03.06.19 at 18:03, wrote:
>>> --- a/xen/include/asm-x86/mm.h
>>> +++ b/xen/include/asm-x86/mm.h
>>> @@ -442,6 +442,8 @@ int check_descriptor(const struct domain *d, seg_desc_t
>>> *desc);
>>>
>>> extern paddr_
>>> On 04.06.19 at 18:11, wrote:
> On 5/31/19 10:53 AM, Jan Beulich wrote:
>> According to Linux commit e75bef2a4f ("arm64: Select
>> ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
>> variant using only bitwise operations on at least some hardware, and no
>> worse on other.
>>
>>> On 04.06.19 at 18:20, wrote:
> On Tue, Jun 04, 2019 at 07:02:06AM -0600, Jan Beulich wrote:
>> >>> On 04.06.19 at 10:48, wrote:
>> > On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
>> >> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
>> >> was redundant
>>> On 05.06.19 at 09:55, wrote:
On 04.06.19 at 18:20, wrote:
>> On Tue, Jun 04, 2019 at 07:02:06AM -0600, Jan Beulich wrote:
>>> >>> On 04.06.19 at 10:48, wrote:
>>> > On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
>>> >> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f
On 31.05.19 13:38, Juergen Gross wrote:
On 30/05/2019 14:46, Boris Ostrovsky wrote:
On 5/30/19 5:04 AM, Christoph Hellwig wrote:
Please don't add your private flag to page-flags.h. The whole point of
the private flag is that you can use it in any way you want withou
touching the common code.
flight 137234 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
test-am
>>> On 04.06.19 at 21:07, wrote:
> On 03/06/2019 09:13, Jan Beulich wrote:
> On 31.05.19 at 22:43, wrote:
>>> On 31/05/2019 02:54, Jan Beulich wrote:
@@ -245,6 +246,9 @@ boot/mkelf32: boot/mkelf32.c
efi/mkreloc: efi/mkreloc.c
$(HOSTCC) $(HOSTCFLAGS) -g -o $@ $<
On Wed, Jun 05, 2019 at 01:55:42AM -0600, Jan Beulich wrote:
> >>> On 04.06.19 at 18:20, wrote:
> > On Tue, Jun 04, 2019 at 07:02:06AM -0600, Jan Beulich wrote:
> >> >>> On 04.06.19 at 10:48, wrote:
> >> > On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
> >> >> This reverts commit b6
On 05/06/2019 10:06, Roger Pau Monné wrote:
>>> On a tangential note, there's also a dereference of dom_xen in
>>> _pci_hide_device which doesn't trigger a page fault. Do we have
>>> something mapped at linear address 0 on purpose?
>> Yes, during early (legacy) boot.
> FWIW, I'm booting from UEFI u
>>> On 05.06.19 at 11:06, wrote:
> On Wed, Jun 05, 2019 at 01:55:42AM -0600, Jan Beulich wrote:
>> >>> On 04.06.19 at 18:20, wrote:
>> > On a tangential note, there's also a dereference of dom_xen in
>> > _pci_hide_device which doesn't trigger a page fault. Do we have
>> > something mapped at lin
Hi Jan,
On 05/06/2019 08:42, Jan Beulich wrote:
On 04.06.19 at 18:11, wrote:
On 5/31/19 10:53 AM, Jan Beulich wrote:
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
variant using only bitwise operations on at least some ha
Hi,
On 05/06/2019 08:14, Jan Beulich wrote:
On 04.06.19 at 18:22, wrote:
On 6/4/19 5:14 PM, Jan Beulich wrote:
On 03.06.19 at 18:03, wrote:
This patch introduces a config option HAS_M2P to tell whether an
architecture implements the M2P.
- iommu_hwdom_init: For now, we require the M2P
>>> On 04.06.19 at 21:51, wrote:
> @@ -163,6 +170,58 @@ void x86_cpuid_policy_fill_native(struct cpuid_policy *p)
> recalculate_synth(p);
> }
>
> +void x86_cpuid_policy_clear_out_of_range_leaves(struct cpuid_policy *p)
> +{
> +unsigned int i;
> +
> +zero_leaves(p->basic.raw, p->bas
>>> On 04.06.19 at 21:51, wrote:
> There is now enough complexity that a fuzzing harness is a good idea, and
> enough supporting logic to implement one which AFL seems happy with.
>
> Take the existing recalculate_synth() helper and export it as
> x86_cpuid_policy_recalc_synth(), as it is needed
On Wed, Jun 05, 2019 at 02:02:43AM -0600, Jan Beulich wrote:
> >>> On 05.06.19 at 09:55, wrote:
> On 04.06.19 at 18:20, wrote:
> >> On Tue, Jun 04, 2019 at 07:02:06AM -0600, Jan Beulich wrote:
> >>> >>> On 04.06.19 at 10:48, wrote:
> >>> > On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beuli
>>> On 04.06.19 at 21:51, wrote:
> These are the final pieces to getting the fuzzing harness working correctly.
I'm mildly confused by this statement, as it seems to imply there was
something not working correctly, when in fact there was nothing at
all - patch 2 only adds a new harness.
Jan
_
On 05/06/2019 10:54, Jan Beulich wrote:
On 04.06.19 at 21:51, wrote:
>> These are the final pieces to getting the fuzzing harness working correctly.
> I'm mildly confused by this statement, as it seems to imply there was
> something not working correctly, when in fact there was nothing at
> a
>>> On 05.06.19 at 11:24, wrote:
> On 05/06/2019 08:42, Jan Beulich wrote:
> On 04.06.19 at 18:11, wrote:
>>> On 5/31/19 10:53 AM, Jan Beulich wrote:
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
variant u
flight 137352 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137352/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen ff7e72a1cac7dfe33ea3c5a528debcead18e0b22
baseline version:
xen 0e62
>>> On 05.06.19 at 11:35, wrote:
> On 05/06/2019 08:14, Jan Beulich wrote:
> On 04.06.19 at 18:22, wrote:
>>> On 6/4/19 5:14 PM, Jan Beulich wrote:
>>> On 03.06.19 at 18:03, wrote:
> This patch introduces a config option HAS_M2P to tell whether an
> architecture implements the M2
>>> On 04.06.19 at 19:22, wrote:
> The only one we could consider is 4.10, but AFAICT Jan already did cut
> the last release for it.
I've sent a call for backport requests. The tree isn't closed yet, but
soon will be.
Jan
___
Xen-devel mailing list
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables
On Tue, Jun 04, 2019 at 06:41:29AM -0600, Jan Beulich wrote:
> Rather than checking that a page table is _not_ "owned" by the fake COW
> domain, check that it's owned by the domain actually wanting to install
> it.
>
> Switch away from BUG_ON() at the same time.
>
> Signed-off-by: Jan Beulich
R
Hi Stefano,
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.
Do you have an example of potential concurr
> On Jun 5, 2019, at 2:27 AM, Baodong Chen wrote:
>
> Xen internal running status(trace event) will be saved to
> trace memory when enabled. trace event data and config params can be
> read/changed by system control hypercall at run time.
>
> Can be disabled for smaller code footprint.
>
> Si
>>> On 03.06.19 at 18:03, wrote:
> p2m_pt_audit_p2m() has one place where the same message may be printed
> twice via printk and P2M_PRINTK.
>
> Remove the one printed using printk to stay consistent with the rest of
> the code.
>
> Take the opportunity to reflow the format of P2M_PRINTK.
Hmm,
Hi Jan,
On 05/06/2019 11:43, Jan Beulich wrote:
On 03.06.19 at 18:03, wrote:
p2m_pt_audit_p2m() has one place where the same message may be printed
twice via printk and P2M_PRINTK.
Remove the one printed using printk to stay consistent with the rest of
the code.
Take the opportunity to reflo
On Thu, May 23, 2019 at 10:41:48AM +0100, Anthony PERARD wrote:
> On Wed, May 22, 2019 at 07:54:42PM +0200, Olaf Hering wrote:
> > Am Wed, 22 May 2019 15:51:40 +0100
> > schrieb Anthony PERARD :
> >
> > > Can you give it a try with one of the affected qemu? (qemu-xen-4.10 or
> > > qemu-xen-4.11)
>
On Tue, Jun 04, 2019 at 08:03:22AM -0600, Jan Beulich wrote:
> while 4.11.2 still suffers delays, 4.10.4 is about due now as well.
> Please point out backports you find missing from its staging tree.
> I have these two already queued
Jan, just to let you know, I'm probably going to apply a patch t
Hi Stefano,
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
On 6/4/19 6:39 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 6/4/19 6:09 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
Hi Jan,
>>> On 03.06.19 at 18:03, wrote:
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -184,7 +184,8 @@ void vcpu_show_registers(const struct vcpu *v)
>
> void show_page_walk(unsigned long addr)
> {
> -unsigned long pfn, mfn = read_cr3() >> PAGE_SHIFT;
> +unsigne
Hi Jan,
Sorry, I seem to have missed the comments on this patch while respinning the
series.
I will look at it and address them in v4.
Cheers,
On 05/06/2019 12:01, Jan Beulich wrote:
On 03.06.19 at 18:03, wrote:
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -184,7
On 05/06/2019 10:59, Jan Beulich wrote:
On 05.06.19 at 11:24, wrote:
On 05/06/2019 08:42, Jan Beulich wrote:
On 04.06.19 at 18:11, wrote:
On 5/31/19 10:53 AM, Jan Beulich wrote:
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement o
>>> On 03.06.19 at 18:03, wrote:
> At the moment, Arm is providing a dummy implementation for the M2P
> helpers used in common code. However, they are quite isolated and could
> be used by other architecture in the future. So move all the helpers in
> xen/mm.h.
And where's the problem then adding
No functional change.
Verified with standalone-generate-dump-flight-runvars.
Signed-off-by: Ian Jackson
---
mfi-common | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/mfi-common b/mfi-common
index 30f2692d..b86febda 100644
--- a/mfi-common
+++ b/mfi-common
@@ -72
Right now there is a bug in, at least, Xen 4.11, where it does not
boot on some of our ARM64 machines but only if CONFIG_LIVEPATCH
is *dis*abled.
We think this is due to Xen not playing by the proper cache management
rules in the ARM ARM. We think that CONFIG_LIVEPATCH is not really
relevant: it
Hi,
On 05/06/2019 12:07, Jan Beulich wrote:
On 03.06.19 at 18:03, wrote:
At the moment, Arm is providing a dummy implementation for the M2P
helpers used in common code. However, they are quite isolated and could
be used by other architecture in the future. So move all the helpers in
xen/mm.h.
Hi Ian,
On 05/06/2019 12:13, Ian Jackson wrote:
Right now there is a bug in, at least, Xen 4.11, where it does not
boot on some of our ARM64 machines but only if CONFIG_LIVEPATCH
is *dis*abled.
We think this is due to Xen not playing by the proper cache management
rules in the ARM ARM. We thin
>>> On 05.06.19 at 13:13, wrote:
> --- a/mfi-common
> +++ b/mfi-common
> @@ -373,7 +373,8 @@ create_build_jobs () {
> fi
> fi
>
> -if branch_wants_livepatch; then
> +if branch_wants_livepatch ||
> + [ $arch = arm64 -a "$xenbranch" = xen-4.11-testing ]; then
>
On 05/06/2019 10:45, Jan Beulich wrote:
On 04.06.19 at 21:51, wrote:
>> @@ -163,6 +170,58 @@ void x86_cpuid_policy_fill_native(struct cpuid_policy
>> *p)
>> recalculate_synth(p);
>> }
>>
>> +void x86_cpuid_policy_clear_out_of_range_leaves(struct cpuid_policy *p)
>> +{
>> +unsigne
On 05/06/2019 10:51, Jan Beulich wrote:
On 04.06.19 at 21:51, wrote:
>> There is now enough complexity that a fuzzing harness is a good idea, and
>> enough supporting logic to implement one which AFL seems happy with.
>>
>> Take the existing recalculate_synth() helper and export it as
>> x86_
Julien Grall writes ("Re: [OSSTEST PATCH 2/2] RFC: enable CONFIG_LIVEPATCH in
all relevant arm64 builds"):
> On 05/06/2019 12:13, Ian Jackson wrote:
> > Switching on CONFIG_LIVEPATCH for the affected tests will, hopefully,
> > make this problem "go away" again. This is clearly a bodge. But it
>
>>> On 27.05.19 at 10:31, wrote:
> During late microcode update, apply_microcode() is invoked in
> cpu_request_microcode(). To make late microcode update more reliable,
> we want to put the apply_microcode() into stop_machine context. So
> we split out it from cpu_request_microcode(). As a consequ
>>> On 05.06.19 at 13:26, wrote:
> On 05/06/2019 10:45, Jan Beulich wrote:
> On 04.06.19 at 21:51, wrote:
>>> @@ -163,6 +170,58 @@ void x86_cpuid_policy_fill_native(struct cpuid_policy
> *p)
>>> recalculate_synth(p);
>>> }
>>>
>>> +void x86_cpuid_policy_clear_out_of_range_leaves(stru
>>> On 05.06.19 at 13:31, wrote:
> On 05/06/2019 10:51, Jan Beulich wrote:
> On 04.06.19 at 21:51, wrote:
>>> There is now enough complexity that a fuzzing harness is a good idea, and
>>> enough supporting logic to implement one which AFL seems happy with.
>>>
>>> Take the existing recalculat
>>> On 05.06.19 at 13:31, wrote:
> I still think it would be better to fix this in the Xen code.
Fully agree. But as Julien says - fully fixing this may be too intrusive
for old branches (provided it gets fixed on master at all).
> Would it be possible to make whether to do "wrong thing A" (whic
>>> On 27.05.19 at 10:31, wrote:
> Updating microcode is less error prone when caches have been flushed and
> depending on what exactly the microcode is updating.
Up to the "and" I understand this sentence, but the rest doesn't really
seem to fit. Taking out the good part it seems to me you're sa
On Tue, Jun 04, 2019 at 08:39:15AM -0600, Jan Beulich wrote:
> >>> On 27.05.19 at 10:31, wrote:
> > --- a/xen/arch/x86/microcode_intel.c
> > +++ b/xen/arch/x86/microcode_intel.c
> > @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num,
> > struct cpu_signature *csig)
> > re
Hi,
On 05/06/2019 14:07, Jan Beulich wrote:
On 05.06.19 at 13:31, wrote:
I still think it would be better to fix this in the Xen code.
Fully agree. But as Julien says - fully fixing this may be too intrusive
for old branches (provided it gets fixed on master at all).
Well we have no other
Hi Ian,
On 05/06/2019 12:31, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH 2/2] RFC: enable CONFIG_LIVEPATCH in all
relevant arm64 builds"):
On 05/06/2019 12:13, Ian Jackson wrote:
Switching on CONFIG_LIVEPATCH for the affected tests will, hopefully,
make this problem "go away"
flight 137258 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-pre
>>> On 27.05.19 at 10:31, wrote:
> This patch ports microcode improvement patches from linux kernel.
>
> Before you read any further: the early loading method is still the
> preferred one and you should always do that. The following patch is
> improving the late loading mechanism for long running
On Tue, Jun 04, 2019 at 06:11:23PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 4/9] libxl_internal: Create new lock for
> devices hotplug via QMP"):
> > The current lock `domain_userdata_lock' can't be used when modification
> > to a guest is done by sending command to QEMU, this is
On Tue, Jun 04, 2019 at 03:41:40PM -0400, Boris Ostrovsky wrote:
> On 6/4/19 12:51 PM, Stefano Stabellini wrote:
> > On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
> >> On 6/3/19 2:25 PM, Stefano Stabellini wrote:
> >>> On Tue, 28 May 2019, Boris Ostrovsky wrote:
> On 5/28/19 6:48 PM, Stefano Stab
>>> On 05.06.19 at 15:22, wrote:
> On Tue, Jun 04, 2019 at 08:39:15AM -0600, Jan Beulich wrote:
>> >>> On 27.05.19 at 10:31, wrote:
>> > --- a/xen/arch/x86/microcode_intel.c
>> > +++ b/xen/arch/x86/microcode_intel.c
>> > @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num,
> s
On Tue, Jun 04, 2019 at 06:47:32PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 9/9] libxl_disk: Implement missing timeout for
> libxl_cdrom_insert"):
> > Since the previous patch "libxl_disk: Use ev_qmp in libxl_cdrom_insert",
> > there are no kind of timeout anymore, add one back.
On 05.06.19 16:13, Konrad Rzeszutek Wilk wrote:
On Tue, Jun 04, 2019 at 03:41:40PM -0400, Boris Ostrovsky wrote:
On 6/4/19 12:51 PM, Stefano Stabellini wrote:
On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
On 6/3/19 2:25 PM, Stefano Stabellini wrote:
On Tue, 28 May 2019, Boris Ostrovsky wrote:
O
guest_handle_subrange_okay() takes inclusive first and last parameters,
i.e. checks that [first, last] is valid. Many callers, however, actually
need to see whether [first, limit) is valid (i.e., limit is non-
inclusive), and to do this they subtract 1 from the size. This is
normally correct, excep
Anthony PERARD writes ("Re: [PATCH 4/9] libxl_internal: Create new lock for
devices hotplug via QMP"):
> So, instead of that interface, how about a different one that uses the
> same C type for both kind of lock?
>
> libxl__lock *libxl__lock_domain_userdata(libxl__gc *, libxl_domid);
> li
Anthony PERARD writes ("Re: [PATCH 9/9] libxl_disk: Implement missing timeout
for libxl_cdrom_insert"):
> On Tue, Jun 04, 2019 at 06:47:32PM +0100, Ian Jackson wrote:
> > But I wonder if this could somehow be placed earlier to preserve
> > bisectability.
>
> I think it would be possible to place
On Mon, May 27, 2019 at 04:31:29PM +0800, Chao Gao wrote:
> This patch ports microcode improvement patches from linux kernel.
>
> Before you read any further: the early loading method is still the
> preferred one and you should always do that. The following patch is
> improving the late loading me
On Mon, May 27, 2019 at 04:31:30PM +0800, Chao Gao wrote:
> microcode_update_lock is to prevent logic threads of a same core from
> updating microcode at the same time. But due to using a global lock, it
> also prevented parallel microcode updating on different cores.
Oh, OK, so that's what I was
>>> On 27.05.19 at 10:31, wrote:
> microcode_update_lock is to prevent logic threads of a same core from
> updating microcode at the same time. But due to using a global lock, it
> also prevented parallel microcode updating on different cores.
>
> Remove this lock in order to update microcode in
On Mon, May 27, 2019 at 04:31:31PM +0800, Chao Gao wrote:
> From: Sergey Dyasli
>
> Currently cpu_sig struct is not updated during boot when either:
>
> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
> 2. initrd does not contain a microcode blob
>
> These will result in
>>> On 27.05.19 at 10:31, wrote:
> From: Sergey Dyasli
>
> Currently cpu_sig struct is not updated during boot when either:
>
> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
> 2. initrd does not contain a microcode blob
I thought we'd already discussed this - "ucode="
>>> On 05.06.19 at 16:52, wrote:
> On Mon, May 27, 2019 at 04:31:30PM +0800, Chao Gao wrote:
>> microcode_update_lock is to prevent logic threads of a same core from
>> updating microcode at the same time. But due to using a global lock, it
>> also prevented parallel microcode updating on differen
On Thu, May 30, 2019 at 8:18 AM Petre Pircalabu
wrote:
>
> Decouple implementation from interface to allow vm_event_check to be
> used regardless of the vm_event underlying implementation.
>
> Signed-off-by: Petre Pircalabu
Acked-by: Tamas K Lengyel
On Thu, May 30, 2019 at 8:18 AM Petre Pircalabu
wrote:
>
> The vm_event_domain members are not accessed outside vm_event.c so it's
> better to hide de implementation details.
>
> Signed-off-by: Petre Pircalabu
Acked-by: Tamas K Lengyel
___
Xen-devel
Julien,
>>> On 16.05.19 at 15:37, wrote:
> As build system now supports *_defconfig rules it is good to be able
> to configure minimal XEN image with
>
> make tiny64_defconfig
>
> command.
>
> Signed-off-by: Volodymyr Babchuk
you had objections here, and the first patch makes little sense
w
Hi Jan,
On 05/06/2019 16:58, Jan Beulich wrote:
Julien,
On 16.05.19 at 15:37, wrote:
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with
make tiny64_defconfig
command.
Signed-off-by: Volodymyr Babchuk
you had objections here, and t
flight 137267 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137267/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
Hi,
On 20/05/2019 23:38, Julien Grall wrote:
On 20/05/2019 22:26, Stefano Stabellini wrote:
On Sat, 11 May 2019, Julien Grall wrote:
This is not about privilege over the system: whoever will make the
decision to ask the hypervisor to map the page will have all the
necessary rights to do it. If
Hi,
On 17/04/2019 22:22, Julien Grall wrote:
On 4/17/19 9:52 PM, Stefano Stabellini wrote:
Gentle ping.
As I said in [1], I don't plan to review v2 because I answered to some of the
issues in v1. You have enough to respin this.
Bumping this. On IRC you mention you have no way forward, howe
On Tue, 2019-06-04 at 15:43 +0100, Andrew Cooper wrote:
> On 30/05/2019 15:18, Petre Pircalabu wrote:
> >
> > Signed-off-by: Petre Pircalabu
>
> There are a number of concerns here.
>
> First and foremost, why is a new domctl being added? Surely this
> should
> just be a "type of ring access"
On 08/05/2019 13:46, Jan Beulich wrote:
> The timer needs to remain active only until all pending IRQ instances
> have seen EOIs from their respective domains. Stop it when the in-flight
> count has reached zero in desc_guest_eoi(). Note that this is race free
> (with __do_IRQ_guest()), as the IRQ
On 08/05/2019 13:46, Jan Beulich wrote:
> There's no point entering the loop in the function in this case. Instead
> there still being something in flight _after_ the loop would be an
> actual problem: No timer would be running anymore for issuing the EOI
> eventually, and hence this IRQ (and possi
On 08/05/2019 13:47, Jan Beulich wrote:
> This is a timer handler, so it gets entered with IRQs enabled. Therefore
> there's no need to save/restore the IRQ masking flag.
>
> Additionally the final switch()'es ACKTYPE_EOI case re-acquires the lock
> just for it to be dropped again right away. Do aw
flight 137270 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137270/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4ff8b6b1d8b74c72fecc7bedb4d791d537eb0310
baseline version:
ovmf 371e7001e8d5753365f3b
On 08/05/2019 13:48, Jan Beulich wrote:
> action->ack_type is set once before the timer even gets initialized, and
> is never changed later. The timer gets activated only for EOI and UNMASK
> types. Hence there's no need to have a respective if() in there. Replace
> it by an ASSERT().
>
> Signed-of
flight 137271 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137271/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 137120
test-armhf-armhf-libvirt-raw 13 saveresto
Jan Beulich writes ("Re: [Xen-devel] [xen-4.7-testing test] 137065: regressions
- FAIL"):
> The one you've picked looks to be a "fail never pass" one, so is perhaps
> not ideal. I've looked at a couple other ones, and in particular when the
> guests are supposedly 64-bit I notice two things
> - th
flight 137269 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137269/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail in 137173 pass in
137269
test-arm64-arm64-examine 11
On Wed, 5 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 05/06/2019 00:11, Stefano Stabellini wrote:
> > On Tue, 4 Jun 2019, Julien Grall wrote:
> > > On 6/4/19 6:39 PM, Stefano Stabellini wrote:
> > > > On Tue, 4 Jun 2019, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > >
> > > > > On 6/4/
On Wed, 5 Jun 2019, Jan Beulich wrote:
> >>> On 05.06.19 at 13:31, wrote:
> > I still think it would be better to fix this in the Xen code.
>
> Fully agree. But as Julien says - fully fixing this may be too intrusive
> for old branches (provided it gets fixed on master at all).
In case it looked
Hi Stefano,
On 6/5/19 9:29 PM, Stefano Stabellini wrote:
On Wed, 5 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
On 6/4/19 6:39 PM, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
No, this
flight 137272 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137272/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
build-i386-prev
On Tue, Jun 04, 2019 at 05:14:14PM +0100, Andrew Cooper wrote:
>On 27/05/2019 09:31, Chao Gao wrote:
>> This patch provides a tool for late microcode update.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Chao Gao
>> ---
>> Changes in v7:
>> - introduce xc_microcode_update() rather
flight 137274 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 137033
Tests which did no
flight 137275 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
90 matches
Mail list logo
