While hunting an issue in swiotlb-xen I stumbled over a wrong test
and found some areas for improvement.
Juergen Gross (3):
xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
xen/swiotlb: simplify range_straddles_page_boundary()
xen/swiotlb: remember having called
range_straddles_page_boundary() is open coding several macros from
include/xen/page.h. Use those instead. Additionally there is no need
to have check_pages_physically_contiguous() as a separate function as
it is used only once, so merge it into range_straddles_page_boundary().
Signed-off-by:
Instead of always calling xen_destroy_contiguous_region() in case the
memory is DMA-able for the used device, do so only in case it has been
made DMA-able via xen_create_contiguous_region() before.
This will avoid a lot of xen_destroy_contiguous_region() calls for
64-bit capable devices.
As the
The condition in xen_swiotlb_free_coherent() for deciding whether to
call xen_destroy_contiguous_region() is wrong: in case the region to
be freed is not contiguous calling xen_destroy_contiguous_region() is
the wrong thing to do: it would result in inconsistent mappings of
multiple PFNs to the
flight 137664 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137664/
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
flight 137663 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137663/
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
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/2019 18:59, Stefano Stabellini wrote:
> > On Thu, 13 Jun 2019, Julien Grall wrote: + * Return values:
> + * XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
> + * was empty, or allocating a new page
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 13/06/2019 19:51, Stefano Stabellini wrote:
> > On Thu, 13 Jun 2019, Julien Grall wrote:
> >> On 6/12/19 11:33 PM, Stefano Stabellini wrote:
> >>> On Tue, 14 May 2019, Julien Grall wrote:
> > I think the basic principle is that with
flight 137654 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137654/
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
Hi Stefano,
On 13/06/2019 18:59, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote: + * Return values:
+ * XEN_TABLE_MAP_FAILED: Either read_only was set and the entry
+ * was empty, or allocating a new page failed.
+ * XEN_TABLE_NORMAL_PAGE: next level
On 13/06/2019 19:04, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote:
>
> Yes, on second thought, a BUG_ON is fine here. The risk is only when the
> BUG_ON could somehow be trigger by guest behavior, which is not the case
> here.
Agreed. I think we are safe to use
Hi Stefano,
On 13/06/2019 19:51, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, Julien Grall wrote:
>> On 6/12/19 11:33 PM, Stefano Stabellini wrote:
>>> On Tue, 14 May 2019, Julien Grall wrote:
> I think the basic principle is that with BUG_ON is "easy" for a guest to
> be able to trigger it,
> >
> > #2 patch says:
> >
> > "> To be symmetric with setting the flag only after having made the
> > region
> > > contiguous, and to avoid (perhaps just theoretical) races, wouldn't
> > it be
> > > better to clear the flag before calling
> > xen_destroy_contiguous_region()?
> >
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:33 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > {set, clear}_fixmap() are currently open-coding update to the Xen
> > > page-tables. This can be avoided by using the generic helpers
> > >
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:41 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > set_pte_flags_on_range() is yet another function that will open-code
> > > update to a specific range in the Xen page-tables. It can be
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:52 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > Currently, xen_pt_update_entry() is only able to update the region covered
> > > by xen_second (i.e 0 to 0x7fff).
> > >
> > > Because
On Thu, 13 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/12/19 11:25 PM, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > Currently, the virtual address of the 3rd level page-tables is obtained
> > > using mfn_to_virt().
> > >
> > > On Arm32, mfn_to_virt can
On Thu, Jun 13, 2019 at 08:08:46AM -0600, Jan Beulich wrote:
> >>> On 13.06.19 at 16:05, wrote:
> > On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
> > On 11.06.19 at 18:04, wrote:
> >>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
> On Wed, Jun 05, 2019 at
flight 137716 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137716/
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 6/13/19 6:19 PM, Tamas Lengyel wrote:
On Wed, Sep 26, 2018 at 10:49 AM George Dunlap wrote:
From: Isaila Alexandru
This patch adds access control for NPT mode.
There aren’t enough extra bits to store the access rights in the NPT p2m
table, so we add a radix tree to store extra
On Wed, Sep 26, 2018 at 10:49 AM George Dunlap wrote:
>
> From: Isaila Alexandru
>
> This patch adds access control for NPT mode.
>
> There aren’t enough extra bits to store the access rights in the NPT p2m
> table, so we add a radix tree to store extra information.
>
> For efficiency:
> - Only
Could we include following commit?
Subject: libxl: keep assigned pci devices across domain reboots
From: Roger Pau Monne roger@citrix.com Thu Sep 20 12:40:25 2018 +0200
Date: Fri Sep 21 17:13:00 2018 +0100:
Git: 99a9c70583bd6dc2555b242353821a32cf1948a9
Thanks,
Charles
On Thu, Jun 13, 2019 at 8:01 AM Razvan Cojocaru
wrote:
>
> Remove myself as vm_event maintaner, add Alexandru and Petre as
> Bitdefender vm_event maintainers.
>
> Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
___
Xen-devel mailing list
On 13.06.19 16:23, Konrad Rzeszutek Wilk wrote:
On Wed, Jun 05, 2019 at 04:24:06PM +0200, Juergen Gross wrote:
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,
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 June 2019 15:47
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; xen-devel de...@lists.xenproject.org>; WeiLiu
> Subject: Re: [PATCH] viridian: unify time sources
>
> >>> On 11.06.19 at 19:01,
On Thu, Jun 13, 2019 at 08:08:46AM -0600, Jan Beulich wrote:
On 13.06.19 at 16:05, wrote:
>> On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
>> On 11.06.19 at 18:04, wrote:
On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
> On Wed, Jun 05, 2019 at
>>> On 11.06.19 at 19:01, wrote:
> @@ -77,6 +76,7 @@ static void update_reference_tsc(struct domain *d, bool
> initialize)
> * ticks per 100ns shifted left by 64.
> */
> p->TscScale = ((1ul << 32) / d->arch.tsc_khz) << 32;
> +p->TscOffset = trc->off;
> smp_wmb();
On 5/29/18 8:06 AM, Olaf Hering wrote:
The function read_vtpmblk uses printf(3), but stdio.h is not included
in this file. This results in a warning from gcc-7:
vtpmblk.c: In function 'read_vtpmblk':
vtpmblk.c:322:7: warning: implicit declaration of function 'printf'
Hi Jan,
On 13/06/2019 14:40, Jan Beulich wrote:
On 13.06.19 at 15:14, wrote:
I am not asking you to spend a lot of time on it. But if you have a gut feeling
this can be done, then a little help would be extremely useful...
... I thought I had already outlined a model: Allow cross-vCPU
>>> On 07.06.19 at 11:22, wrote:
> @@ -817,7 +811,7 @@ static u64 read_pci_mem_bar(u16 seg, u8 bus, u8 slot, u8
> func, u8 bir, int vf)
> if ( ++bir >= limit )
> return 0;
> return addr + disp +
> - ((u64)pci_conf_read32(seg, bus, slot, func,
> +
>>> On 07.06.19 at 11:22, wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
On Wed, Jun 05, 2019 at 04:24:06PM +0200, Juergen Gross wrote:
> 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
>>> On 07.06.19 at 11:22, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -420,12 +420,12 @@ static void disable_c1_ramping(void)
> nr_nodes = ((pci_conf_read32(0, 0, 0x18, 0x0, 0x60)>>4)&0x07)+1;
> for (node = 0; node < nr_nodes; node++) {
> /*
>>> On 13.06.19 at 16:05, wrote:
> On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
> On 11.06.19 at 18:04, wrote:
>>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>
>> @@ -307,8 +303,7 @@
flight 137641 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail REGR. vs.
On Wed, Jun 12, 2019 at 01:38:31AM -0600, Jan Beulich wrote:
On 11.06.19 at 18:04, wrote:
>> On Tue, Jun 11, 2019 at 08:46:04PM +0800, Chao Gao wrote:
>>> On Wed, Jun 05, 2019 at 08:53:46AM -0600, Jan Beulich wrote:
>>> >
>>> >> @@ -307,8 +303,7 @@ static int apply_microcode(const struct
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
---
Re-sent to add Tamas', Petre's and Alexandru's addresses.
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS
>>> On 13.06.19 at 15:14, wrote:
> On 13/06/2019 13:58, Jan Beulich wrote:
> On 13.06.19 at 14:48, wrote:
>>> On 13/06/2019 13:41, Jan Beulich wrote:
>>> On 13.06.19 at 14:32, wrote:
> On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in
While for 32-bit IRTEs I think we can safely continue to assume that the
writes will translate to a single MOV, the use of CMPXCHG16B is more
heavy handed than necessary for the 128-bit form, and the flushing
didn't get done along the lines of what the specification says. Mark
entries to be
In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
switched into suitable state.
The post-AP-bringup IRQ affinity adjustment is done also for the non-
x2APIC case.
Signed-off-by: Jan Beulich
---
TBD: Instead of the system_state check in iov_enable_xt() the function
In order to be able to express all possible destinations we need to make
use of this non-MSI-capability based mechanism. The new IRQ controller
structure can re-use certain MSI functions, though.
For now general and PPR interrupts still share a single vector, IRQ, and
hence handler.
Early enabling (to enter x2APIC mode) requires deferring of the IRQ
setup. Code to actually do that setup in the x2APIC case will get added
subsequently.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -814,7 +814,6 @@
Mapping the MMIO space and obtaining feature information needs to happen
slightly earlier, such that for x2APIC support we can set XTEn prior to
calling amd_iommu_update_ivrs_mapping_acpi() and
amd_iommu_setup_ioapic_remapping().
Signed-off-by: Jan Beulich
---
This is in preparation of actually enabling x2APIC mode, which requires
this wider IRTE format to be used.
A specific remark regarding the first hunk changing
amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
i.e. by 94d4a1119d ("AMD,IOMMU: Clean up old entries in remapping
This also takes care of several of the shift values wrongly having been
specified as hex rather than dec.
Take the opportunity and add further fields.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -60,43 +60,72
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by introducing a union of
pointers. (A union of the actual table entries is not used to make it
impossible to [wrongly, once the 128-bit form gets added] perform
pointer arithmetic / array
Also introduce a field in struct amd_iommu caching the most recently
written control register. All writes should now happen exclusively from
that cached value, such that it is guaranteed to be up to date.
Take the opportunity and add further fields. Also convert a few boolean
function parameters
>>> On 13.06.19 at 15:11, wrote:
> On 13/06/2019 14:06, Jan Beulich wrote:
>> It is only of limited use to check the full accumulated 32-bit value,
>> because the high halves are the cluster ID. What needs to be non-zero is
>> the bit map at the bottom, or else APIC errors will result.
>>
>>
Despite the title this is actually all AMD IOMMU side work; all x86
side adjustments have already been carried out.
If in doubt, the series is assumed to go on top of
AMD/IOMMU: initialize IRQ tasklet only once [1]
AMD/IOMMU: revert "amd/iommu: assign iommu devices to Xen" [2]
AMD/IOMMU: don't
Hi Jan,
On 13/06/2019 13:58, Jan Beulich wrote:
On 13.06.19 at 14:48, wrote:
Hi Jan,
On 13/06/2019 13:41, Jan Beulich wrote:
On 13.06.19 at 14:32, wrote:
Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on
On 13/06/2019 14:06, Jan Beulich wrote:
> It is only of limited use to check the full accumulated 32-bit value,
> because the high halves are the cluster ID. What needs to be non-zero is
> the bit map at the bottom, or else APIC errors will result.
>
> Signed-off-by: Jan Beulich
I take it you
It is only of limited use to check the full accumulated 32-bit value,
because the high halves are the cluster ID. What needs to be non-zero is
the bit map at the bottom, or else APIC errors will result.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/x2apic.c
+++
>>> On 13.06.19 at 14:48, wrote:
> Hi Jan,
>
> On 13/06/2019 13:41, Jan Beulich wrote:
> On 13.06.19 at 14:32, wrote:
>>> Jan, Julien,
>>>
>>> On 11.06.19 12:10, Jan Beulich wrote:
>> At the very least such loops want a cpu_relax() in their bodies.
>> But this being on a hypercall
Hi Jan,
On 13/06/2019 13:41, Jan Beulich wrote:
On 13.06.19 at 14:32, wrote:
Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse
>>> On 13.06.19 at 14:32, wrote:
> Jan, Julien,
>
> On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse this to lock up a CPU?
>>>
flight 137639 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137639/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 137269
test-amd64-amd64-xl-qemuu-win7-amd64
>>> On 13.06.19 at 14:21, wrote:
> On 11.06.19 13:22, Andrii Anisov wrote:
>> On 11.06.19 12:10, Jan Beulich wrote:
> Except when there's no need for KPTI in the guest in the first place,
> as is the case for x86-64 PV guests. I think this is worthwhile
> clarifying.
I am
>>> On 13.06.19 at 14:17, wrote:
> On 12.06.19 10:27, Jan Beulich wrote:
>>> Well, my point here is to left it as is, maybe add more documentation. If
>>> one likes shooting his leg, we should only care about avoiding ricochet
> harms
>>> hypervisor or other guests.
>>> If you disagree, please
Jan, Julien,
On 11.06.19 12:10, Jan Beulich wrote:
At the very least such loops want a cpu_relax() in their bodies.
But this being on a hypercall path - are there theoretical guarantees
that a guest can't abuse this to lock up a CPU?
Hmmm, I suggested this but it looks like a guest may call
Jan,
On 11.06.19 13:22, Andrii Anisov wrote:
Hello Jan,
On 11.06.19 12:10, Jan Beulich wrote:
Except when there's no need for KPTI in the guest in the first place,
as is the case for x86-64 PV guests. I think this is worthwhile clarifying.
I am not sure what is your point here. At least on
Jan,
On 12.06.19 10:27, Jan Beulich wrote:
Well, my point here is to left it as is, maybe add more documentation. If
one likes shooting his leg, we should only care about avoiding ricochet harms
hypervisor or other guests.
If you disagree, please suggest your interaction model, I'll be happy to
Hi,
On 14/05/2019 13:24, Julien Grall wrote:
This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.
The first part of the rework is "xen/arm: TLB flush helpers rework" [1].
For convenience, I provided a branch with
Hi Stefano,
On 08/06/2019 01:17, Stefano Stabellini wrote:
On Wed, 5 Jun 2019, Julien Grall wrote:
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
Please review this patch.
Am Tue, 29 May 2018 14:06:48 +0200
schrieb Olaf Hering :
> The function read_vtpmblk uses printf(3), but stdio.h is not included
> in this file. This results in a warning from gcc-7:
>
> vtpmblk.c: In function 'read_vtpmblk':
> vtpmblk.c:322:7: warning: implicit
On 26.09.2018 19:47, George Dunlap wrote:
> From: Isaila Alexandru
>
> This patch adds access control for NPT mode.
>
> There aren’t enough extra bits to store the access rights in the NPT p2m
> table, so we add a radix tree to store extra information.
>
> For efficiency:
> - Only allocate
Hi Stefano,
On 6/12/19 11:41 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or
чт, 13 черв. 2019 о 11:39 Juergen Gross пише:
> github.com/jgross1/xen sched-v1-rebase
>
> Only compile tested on x86 up to now, but rebase was rather easy.
>
Cool, will take it and check for ARM.
Thank you.
Sincerely,
Andrii Anisov.
___
Xen-devel
On 13.06.19 09:34, Andrii Anisov wrote:
On 13.06.19 10:29, Juergen Gross wrote:
Thanks for the heads up, but I've rebased already. :-)
Oh, great. I'm just wondering if you put it already on your github?
github.com/jgross1/xen sched-v1-rebase
Only compile tested on x86 up to now, but
Hi Stefano,
On 6/12/19 11:33 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().
Both function are
Hi Stefano,
On 6/12/19 11:52 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying
Hi Stefano,
On 6/12/19 11:25 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().
On Arm32, mfn_to_virt can only work on xenheap page. While in practice
all the page-tables updated
On 13.06.19 10:29, Juergen Gross wrote:
Thanks for the heads up, but I've rebased already. :-)
Oh, great. I'm just wondering if you put it already on your github?
I'm playing with scheduling on my site, and I have a strong feeling I should be
based on your series ;)
--
Sincerely,
Andrii
Hi Andrii,
On 13.06.19 09:18, Andrii Anisov wrote:
Hello Juergen,
Please note that this patch will clash with [1].
On 28.05.19 13:32, Juergen Gross wrote:
vcpu->last_run_time is primarily used by sched_credit, so move it to
struct sched_unit, too.
`last_run_time` is moved to credit
Hello Juergen,
Please note that this patch will clash with [1].
On 28.05.19 13:32, Juergen Gross wrote:
vcpu->last_run_time is primarily used by sched_credit, so move it to
struct sched_unit, too.
`last_run_time` is moved to credit privates as for current staging.
[1]
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. The current
flush_tlb_others() interface is kept, since paravirtual interfaces need
to be adapted first before it can be removed. This is left for future
work. In such PV
75 matches
Mail list logo
