On 29.07.19 20:03, Andrew Cooper wrote:
On 29/07/2019 14:54, Jan Beulich wrote:
On 29.07.2019 15:23, Andrew Cooper wrote:
On 29/07/2019 14:00, Jan Beulich wrote:
On 26.07.2019 23:08, Andrew Cooper wrote:
--- a/xen/include/xen/percpu.h
+++ b/xen/include/xen/percpu.h
@@ -3,6 +3,12 @@
flight 139533 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139533/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3d34b5f32692c84bbc69ff34a9ea511bcb55e50a
baseline version:
ovmf
From: Nadav Amit Sent: Thursday, July 18, 2019 5:59 PM
>
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. Introduce
> paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
> and hyper-v are only
On Tue, Jul 23, 2019 at 7:16 PM Adam Williamson
wrote:
>
> OK, so, to move forward with this (and looping in cloud list): does
> someone want to propose a set (ideally small - 2 would be great, one
> Xen and one non-Xen, if we can cover most common usages that way!) of
> EC2 instance types we
flight 139525 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR.
vs. 139300
On Wed, 2019-06-19 at 15:03 +0200, Olaf Hering wrote:
> In the near future all fresh installations will have an empty /etc.
> The content of this directory will not be controlled by the package
> manager anymore. One of the reasons for this move is to make
> snapshots
> more robust.
>
>
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> This prepares support of larger scheduling granularities, e.g. core
> scheduling.
>
> While at it move sched_has_urgent_vcpu() from include/asm-
> x86/cpuidle.h
> into schedule.c removing the need for including sched-if.h in
> cpuidle.h
On Tue, 2019-07-30 at 17:23 +0100, Andrew Cooper wrote:
> On 30/07/2019 16:51, Jan Beulich wrote:
> > On 25.07.2019 02:53, christopher.w.cl...@gmail.com wrote:
> > > From: Christopher Clark
> > >
> > > gcc 9.1.0 reports:
> > >
> > > > test-cpu-policy.c:64:18: error: '%.12s' directive argument
flight 139521 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139521/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
> All that said, the first question I think is, what the generated code
> needs to look like. Then, if c-for-go can be configured to do that,
> then we can consider it; otherwise, making our own generator from the
> IDL will be the only option.
Writing a custom Go code generator means that all C
On 30/07/2019 22:21, Stefano Stabellini wrote:
> On Mon, 22 Jul 2019, Julien Grall wrote:
>> Boot CPU and secondary CPUs will use different entry point to C code. At
>> the moment, the decision on which entry to use is taken within launch().
>>
>> In order to avoid using conditional instruction
On Mon, 22 Jul 2019, Julien Grall wrote:
> At the moment BSS is zeroed before the MMU and D-Cache is turned on.
> In other words, the cache will be bypassed when zeroing the BSS section.
>
> On Arm64, per the Image protocol [1], the state of the cache for BSS region
> is not known because it is
On Mon, 22 Jul 2019, Julien Grall wrote:
> At the moment, HTTBR is setup in create_page_tables(). This is fine as
> it is called by every CPUs.
>
> However, such assumption may not hold in the future. To make change
> easier, the HTTBR is not setup in enable_mmu().
>
> Take the opportunity to
On Mon, 22 Jul 2019, Julien Grall wrote:
> Boot CPU and secondary CPUs will use different entry point to C code. At
> the moment, the decision on which entry to use is taken within launch().
>
> In order to avoid using conditional instruction and make the call
> clearer, launch() is reworked to
On Mon, 22 Jul 2019, Julien Grall wrote:
> At the moment, the fixmap table is only hooked when earlyprintk is used.
> This is fine today because in C land, the fixmap is not used by anyone
> until the the boot CPU is switching to the runtime page-tables.
>
> In the future, the boot CPU will not
On Mon, 22 Jul 2019, Julien Grall wrote:
> The current boot code is using the pattern ldr rX, =... to move an
> immediate constant into a 32-bit register.
>
> This pattern implies to load the immediate constant from a literal pool,
> meaning a memory access will be performed.
>
> The memory
flight 139513 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139513/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 8 reboot fail REGR. vs. 139484
Tests which did
Hi Stefano,
On 7/30/19 9:25 PM, Stefano Stabellini wrote:
On Mon, 22 Jul 2019, Julien Grall wrote:
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
(+ Andre)
On 7/30/19 6:34 PM, Andrii Anisov wrote:
Hello Julien,
It looks I missed answering this email. So do this now:
On 29.11.18 00:00, Julien Grall wrote:
On 28/11/2018 21:31, Andrii Anisov wrote:
From: Julien Grall
This makes function enter_hypervisor_head() being executed with
irqs
On Mon, 22 Jul 2019, Julien Grall wrote:
> setup_fixmap() will setup the fixmap in the boot page tables in order to
> use earlyprintk and also update the register r11 holding the address to
> the UART.
>
> However, secondary CPUs are not using earlyprintk between turning the
> MMU on and
On Mon, 22 Jul 2019, Julien Grall wrote:
> The assembly switch to the runtime PT is only necessary for the
> secondary CPUs. So move the code in the secondary CPUs path.
>
> While this is definitely not compliant with the Arm Arm as we are
> switching between two differents set of page-tables
On Mon, 22 Jul 2019, Julien Grall wrote:
> Document the behavior and the main registers usage within enable_mmu().
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Patch added
> ---
> xen/arch/arm/arm32/head.S | 7 +++
> 1 file
On Mon, 22 Jul 2019, Julien Grall wrote:
> Document the behavior and the main registers usage within the function.
> Note that r6 is now only used within the function, so it does not need
> to be part of the common register.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
On Mon, 22 Jul 2019, Julien Grall wrote:
> On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
> zeroed once at boot. So the call in the secondary CPUs path can be
> removed.
>
> Lastly, document the behavior and the main registers usage within the
> function.
>
>
On Mon, 22 Jul 2019, Julien Grall wrote:
> A branch in the success case can be avoided by inverting the branch
> condition. At the same time, remove a pointless comment as Xen can only
> run at Hypervisor Mode.
>
> Lastly, document the behavior and the main registers usage within the
> function.
On Mon, 22 Jul 2019, Julien Grall wrote:
> The boot code is currently quite difficult to go through because of the
> lack of documentation and a number of indirection to avoid executing
> some path in either the boot CPU or secondary CPUs.
>
> In an attempt to make the boot code easier to follow,
On 7/30/19 2:34 PM, Souptick Joarder wrote:
> 'commit df9bde015a72 ("xen/gntdev.c: convert to use vm_map_pages()")'
> breaks gntdev driver. If vma->vm_pgoff > 0, vm_map_pages()
> will:
> - use map->pages starting at vma->vm_pgoff instead of 0
> - verify map->count against
Hi,
On 7/30/19 7:24 PM, Stefano Stabellini wrote:
On Mon, 22 Jul 2019, Julien Grall wrote:
Arm64 provides instructions to load a PC-relative address, but with some
limitations:
- adr is enable to cope with +/-1MB
- adrp is enale to cope with +/-4GB but relative to a 4KB page
Hi Stefano,
On 7/30/19 6:33 PM, Stefano Stabellini wrote:
On Thu, 27 Jun 2019, Julien Grall wrote:
On 6/27/19 7:55 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
+1:
+/*
+ * Find the second slot used. Remove the entry for the first
+ * table if
On Mon, 22 Jul 2019, Julien Grall wrote:
> At the moment, the user should save r14/lr if it cares about it.
>
> Follow-up patches will introduce more use of putn in place where lr
> should be preserved.
>
> Furthermore, any user of putn should also move the value to register r0
> if it was
On Mon, 22 Jul 2019, Julien Grall wrote:
> Anything executed after the label common_start can be executed on all
> CPUs. However most of the instructions executed between the label
> common_start and init_uart are not executed on the boot CPU.
>
> The only instructions executed are to lookup the
On Mon, 22 Jul 2019, Julien Grall wrote:
> The current implementation of the macro PRINT will clobber r14/lr. This
> means the user should save r14 if it cares about it.
>
> Follow-up patches will introduce more use of PRINT in places where lr
> should be preserved. Rather than requiring all the
On Mon, 22 Jul 2019, Julien Grall wrote:
> putn() and puts() are two subroutines. Add ENDPROC for the benefits of
> static analysis tools and the reader.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - Patch added
> ---
>
On Tue, Jul 30, 2019 at 9:49 AM George Dunlap wrote:
>
> On 7/30/19 2:48 PM, Tamas K Lengyel wrote:
> > On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
> > wrote:
> >>
> >> Hello,
> >>
> >> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> >> summit earlier this
'commit df9bde015a72 ("xen/gntdev.c: convert to use vm_map_pages()")'
breaks gntdev driver. If vma->vm_pgoff > 0, vm_map_pages()
will:
- use map->pages starting at vma->vm_pgoff instead of 0
- verify map->count against vma_pages()+vma->vm_pgoff instead of just
vma_pages().
In practice, this
On Mon, 22 Jul 2019, Julien Grall wrote:
> Arm64 provides instructions to load a PC-relative address, but with some
> limitations:
>- adr is enable to cope with +/-1MB
>- adrp is enale to cope with +/-4GB but relative to a 4KB page
> address
>
> Because of that, the code requires to
On Mon, 22 Jul 2019, Julien Grall wrote:
> At the moment, TTBR_EL2 is setup in create_page_tables(). This is fine
> as it is called by every CPUs.
>
> However, such assumption may not hold in the future. To make change
> easier, the TTBR_EL2 is not setup in enable_mmu().
>
> Take the opportunity
On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich wrote:
>
> On 23.07.2019 20:25, Roman Shaposhnik wrote:
> > Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
> > booted the system just fine.
>
> Btw (I've noticed this only now) - are you saying without "iommu=debug"
> the box
Hi all,
the proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/arfa2Pr3D2uIuEN3EWNTdOVT/
Alternatively, you can reply to this mail directly
Agenda items appreciated by tomorrow
Regards
Lars
P.S.: If you want to be added or removed from the CC list please reply privately
== Dial-in
On 30/07/2019 12:26, Jan Beulich wrote:
> On 29.07.2019 14:12, Andrew Cooper wrote:
>> --- a/xen/include/xen/nodemask.h
>> +++ b/xen/include/xen/nodemask.h
>> @@ -11,7 +11,9 @@
>> * The available nodemask operations are:
>> *
>> * void node_set(node, mask)turn on bit 'node'
On Mon, 22 Jul 2019, Julien Grall wrote:
> Boot CPU and secondary CPUs will use different entry point to C code. At
> the moment, the decision on which entry to use is taken within launch().
>
> In order to avoid a branch for the decision and make the code clearer,
> launch() is reworked to take
On Mon, 22 Jul 2019, Julien Grall wrote:
> At the moment, the fixmap table is only hooked when earlyprintk is used.
> This is fine today because in C land, the fixmap is not used by anyone
> until the the boot CPU is switching to the runtime page-tables.
>
> In the future, the boot CPU will not
On 26.07.19 13:48, Julien Grall wrote:
This is the 3rd time you send this patch... and still no proper explanation why
this is done nor the impact on keeping the interrupts disabled longer than
necessary.
I know it is the third time for this patch. Yet it is in the RFC series again.
In this
Hello Julien,
It looks I missed answering this email. So do this now:
On 29.11.18 00:00, Julien Grall wrote:
On 28/11/2018 21:31, Andrii Anisov wrote:
From: Julien Grall
This makes function enter_hypervisor_head() being executed with
irqs locked. This also give a fine side effect - it
On 26.07.19 13:59, Julien Grall wrote:
Hi,
On 26/07/2019 11:37, Andrii Anisov wrote:
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function
On 30/07/2019 09:09, Jan Beulich wrote:
> On 29.07.2019 19:26, Andrew Cooper wrote:
>> On 29/07/2019 16:48, Jan Beulich wrote:
>>> On 29.07.2019 14:11, Andrew Cooper wrote:
+if ( d )
+nodes_and(nodemask, nodemask, d->node_affinity);
>>> Despite my earlier ack: Code further
On Mon, 22 Jul 2019, Julien Grall wrote:
> Document the behavior and the main registers usage within enable_mmu().
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - x2 and x3 are also clobbers. Update the comment accordingly
> -
On Mon, 22 Jul 2019, Julien Grall wrote:
> Adjust the coding style used in the comments within create_pages_tables()
>
> Lastly, document the behavior and the main registers usage within the
> function. Note that x25 is now only used within the function, so it does
> not need to be part of the
On Mon, 22 Jul 2019, Julien Grall wrote:
> Adjust the coding style used in the comments within cpu_init(). Take the
> opportunity to alter the early print to match the function name.
>
> Lastly, document the behavior and the main registers usage within the
> function.
>
> Signed-off-by: Julien
flight 139516 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139516/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139476
test-armhf-armhf-libvirt-raw 13
On Mon, 22 Jul 2019, Julien Grall wrote:
> On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
> zeroed once at boot. So the call in the secondary CPUs path can be
> removed. It also means that x26 does not need to be set for secondary
> CPU.
>
> Note that we will need to keep
c/s 201f852eaf added start_info.h and kconfig.h to reloc.c, but only updated
start_info.h in RELOC_DEPS.
This causes reloc.c to not be regenerated when Kconfig changes. It is most
noticeable when enabling CONFIG_PVH and finding the resulting binary crash
early with:
(d9) (XEN)
(d9) (XEN)
On Mon, 22 Jul 2019, Julien Grall wrote:
> The boot code is currently quite difficult to go through because of the
> lack of documentation and a number of indirection to avoid executing
> some path in either the boot CPU or secondary CPUs.
>
> In an attempt to make the boot code easier to follow,
flight 139529 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139529/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Tue, 30 Jul 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 7/29/19 11:02 PM, Stefano Stabellini wrote:
> > On Tue, 23 Jul 2019, Julien Grall wrote:
> > > At the moment, do_trap_brk() is using a BUG_ON() to check the hardware
> > > has been correctly configured during boot.
> > >
> > > Any
flight 139518 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139518/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8fed4e47d9a64a3d047f74b5f465f554d3d912a4
baseline version:
ovmf
Since commit ec83f825627 "mm.h: add helper function to test-and-clear
_PGC_allocated" (and subsequent fix-up 44a887d021d "mm.h: fix BUG_ON()
condition in put_page_alloc_ref()") setting grant table version from 2
back to 1 has been vulnerable to hitting the BUG_ON in put_page_alloc_ref()
during
flight 139509 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
On Thu, Jul 25, 2019 at 01:33:24PM +, Jan Beulich wrote:
> Log SBDF headers only when there are actual IRTEs to log. This is
> particularly important for the total volume of output when the ACPI
> tables describe far more than just the existing devices. On my Rome
> system so far there was one
On 30/07/2019 10:49, Jan Beulich wrote:
> On 30.07.2019 11:35, Andrew Cooper wrote:
>> On 30/07/2019 09:42, Jan Beulich wrote:
>>> On 29.07.2019 19:38, Andrew Cooper wrote:
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -293,14 +293,17 @@ SECTIONS
On Thu, Jul 25, 2019 at 01:31:02PM +, Jan Beulich wrote:
> 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
On Thu, Jul 25, 2019 at 01:29:16PM +, Jan Beulich wrote:
> This also takes care of several of the shift values wrongly having been
> specified as hex rather than dec.
>
> Take the opportunity and
> - replace a readl() pair by a single readq(),
> - add further fields.
>
> Signed-off-by: Jan
On 7/30/19 2:11 PM, Nicholas Rosbrook wrote:
> Hello,
>
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would
> like to open
> a discussion around the development of Go bindings for libxl. George
On 30/07/2019 16:51, Jan Beulich wrote:
> On 25.07.2019 02:53, christopher.w.cl...@gmail.com wrote:
>> From: Christopher Clark
>>
>> gcc 9.1.0 reports:
>>
>> | test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
>> nul-terminated string [-Werror=format-overflow=]
>> |64 |
On 25.07.2019 02:53, christopher.w.cl...@gmail.com wrote:
> From: Christopher Clark
>
> gcc 9.1.0 reports:
>
> | test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
> nul-terminated string [-Werror=format-overflow=]
> |64 | fail(" Test '%.12s', expected vendor
On 7/30/19 2:48 PM, Tamas K Lengyel wrote:
> On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
> wrote:
>>
>> Hello,
>>
>> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
>> summit earlier this month, "Client Virtualization Toolstack in Go", I would
>> like to open
>>
On 30.07.2019 17:54, Jan Beulich wrote:
> On 30.07.2019 16:12, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 30.07.2019 16:27, Jan Beulich wrote:
>>> On 30.07.2019 14:21, Alexandru Stefan ISAILA wrote:
> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>
On 7/30/19 2:11 PM, Nicholas Rosbrook wrote:
> Hello,
>
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would
> like to open
> a discussion around the development of Go bindings for libxl. George
On 30.07.2019 16:12, Alexandru Stefan ISAILA wrote:
>
>
> On 30.07.2019 16:27, Jan Beulich wrote:
>> On 30.07.2019 14:21, Alexandru Stefan ISAILA wrote:
>>>
@@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
ASSERT(p2mt ==
On Tue, Jul 30, 2019 at 08:22:02PM +0530, Souptick Joarder wrote:
> On Tue, Jul 30, 2019 at 7:52 PM Marek Marczykowski-Górecki
> wrote:
> >
> > On Tue, Jul 30, 2019 at 10:05:42AM -0400, Boris Ostrovsky wrote:
> > > On 7/30/19 2:03 AM, Souptick Joarder wrote:
> > > > On Mon, Jul 29, 2019 at 7:06
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-raw
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: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Tue, Jul 30, 2019 at 7:52 PM Marek Marczykowski-Górecki
wrote:
>
> On Tue, Jul 30, 2019 at 10:05:42AM -0400, Boris Ostrovsky wrote:
> > On 7/30/19 2:03 AM, Souptick Joarder wrote:
> > > On Mon, Jul 29, 2019 at 7:06 PM Marek Marczykowski-Górecki
> > > wrote:
> > >> On Mon, Jul 29, 2019 at
c/s e9986b0dd "x86/vvmx: Simplify per-CPU memory allocations" had the wrong
indirection on its pointer check in nvmx_cpu_up_prepare(), causing the
VMCS-shadowing buffer never be allocated. Fix it.
This in turn results in a massive quantity of logspam, as every virtual
vmentry/exit hits both
On Tue, Jul 30, 2019 at 10:05:42AM -0400, Boris Ostrovsky wrote:
> On 7/30/19 2:03 AM, Souptick Joarder wrote:
> > On Mon, Jul 29, 2019 at 7:06 PM Marek Marczykowski-Górecki
> > wrote:
> >> On Mon, Jul 29, 2019 at 02:02:54PM +0530, Souptick Joarder wrote:
> >>> On Mon, Jul 29, 2019 at 1:35 PM
On 30.07.2019 15:42, Andrew Cooper wrote:
> On 25/07/2019 14:33, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
>> @@ -107,57 +107,60 @@
>>#define IOMMU_DEV_TABLE_INT_CONTROL_FORWARDED 0x1
>>#define
On 7/30/19 15:38, Jan Beulich wrote:
> On 30.07.2019 15:15, Norbert Manthey wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative out-of-bound accesses,
On 30.07.2019 16:27, Jan Beulich wrote:
> On 30.07.2019 14:21, Alexandru Stefan ISAILA wrote:
>>
>>> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>>>
>>> ASSERT(p2mt == p2m_ram_logdirty ||
>>> !p2m_is_readonly(p2mt));
>>>
On 7/30/19 2:03 AM, Souptick Joarder wrote:
> On Mon, Jul 29, 2019 at 7:06 PM Marek Marczykowski-Górecki
> wrote:
>> On Mon, Jul 29, 2019 at 02:02:54PM +0530, Souptick Joarder wrote:
>>> On Mon, Jul 29, 2019 at 1:35 PM Souptick Joarder
>>> wrote:
On Sun, Jul 28, 2019 at 11:36 PM Marek
On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
wrote:
>
> Hello,
>
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would
> like to open
> a discussion around the development of Go bindings for
On 30.07.2019 15:18, Paul Durrant wrote:
> The hap_enabled() macro can determine whether the feature is available
> using the domain 'options'; there is no need for a separate flag.
>
> NOTE: Furthermore, by extending sanitiziing of the domain 'options', the
>macro can be transformed into
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
This series is base on my recent 'use stashed domain create flags'
series [1] and Alexandru Isaila's 'Clean iommu_hap_pt_share enabled code'
patch [2]. It ultimately introduces a new 'passthrough' option to xl.cfg to
provide per-domain control over a guests IOMMU mappings.
[1]
This function is only ever called from within the same source module and
really has no business being declared xen/iommu.h. This patch relocates
the function ahead of the first called and makes it static.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
---
xen/drivers/passthrough/pci.c | 92
Now that there is a per-domain IOMMU enable flag, which should be enabled if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
...rather than testing the global iommu_enabled flag and ops pointer.
Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be
This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled.
This patch gates calls to iommu_domain_init() on the new flag. The function
was
On 30.07.2019 15:15, Norbert Manthey wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is used as index for memory loads after bound
> checks have been done. To avoid speculative out-of-bound accesses, we
> use the array_index_nospec macro
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as
On 25/07/2019 14:33, Jan Beulich wrote:
> --- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
> +++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
> @@ -107,57 +107,60 @@
> #define IOMMU_DEV_TABLE_INT_CONTROL_FORWARDED 0x1
> #define IOMMU_DEV_TABLE_INT_CONTROL_TRANSLATED 0x2
>
>
On 30.07.2019 14:21, Alexandru Stefan ISAILA wrote:
>
>> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>>
>>ASSERT(p2mt == p2m_ram_logdirty ||
>> !p2m_is_readonly(p2mt));
>>}
>> +
>> +if (
flight 139523 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139523/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
Hello,
As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
summit earlier this month, "Client Virtualization Toolstack in Go", I would
like to open
a discussion around the development of Go bindings for libxl. George Dunlap,
Nicolas Belouin and I have had some discussion
On 30.07.2019 14:44, Norbert Manthey wrote:
> On 7/18/19 14:09, Jan Beulich wrote:
>> On 12.07.2019 10:51, Norbert Manthey wrote:
>>> Guests can issue grant table operations and provide guest controlled
>>> data to them. This data is used as index for memory loads after bound
>>> checks have been
Paul Durrant (5):
domain: remove 'guest_type' field (and enum guest_type)
x86/hvm/domain: remove the 'hap_enabled' flag
x86/domain: remove the 'oos_off' flag
domain: remove the 'is_xenstore' flag
x86/domain: remove the 's3_integrity' flag
xen/arch/x86/domain.c| 22
The enum guest_type was introduced in commit 6c6492780ea "pvh prep:
introduce pv guest type and has_hvm_container macros" to allow a new guest
type, distinct from either PV or HVM guest types, to be added in commit
8271d6522c6 "pvh: introduce PVH guest type". Subsequently, commit
33e5c32559e "x86:
This patch introduces a convenience macro, is_xenstore_domain(), which
tests the domain 'options' directly and then uses that in place of
the 'is_xenstore' flag.
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
Acked-by: George Dunlap
---
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Jan
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: "Roger Pau Monné"
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
v4:
- s/TBOOT/CONFIG_TBOOT/g
v3:
- Also sanitise the flag against CONFIG_TBOOT being set
---
The flag is not needed since the domain 'options' can now be tested
directly.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Tim Deegan
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v3:
- Force 'oos_off' to be set for PV guests (to avoid call to
The hap_enabled() macro can determine whether the feature is available
using the domain 'options'; there is no need for a separate flag.
NOTE: Furthermore, by extending sanitiziing of the domain 'options', the
macro can be transformed into an inline function and re-located to
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. Depending on the grant table version, the
size of elements in containers differ. As the base data structure is
a page, the number of
1 - 100 of 175 matches
Mail list logo
