On 21.01.21 08:55, Jan Beulich wrote:
On 20.01.2021 19:20, Julien Grall wrote:
On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pass the function pointer via a
register (this needs to be done that way,
On Thu, 2021-01-21 at 01:20 +, Volodymyr Babchuk wrote:
> Hi Dario,
>
Hi :-)
> Dario Faggioli writes:
> > Anyway, as I was saying, having a latency which is ~ 2x of your
> > period
> > is ok, and it should be expected (when you size the period). In
> > fact,
> > let's say that your budget is
On 20.01.21 17:50, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 17/01/2021 18:52, Oleksandr wrote:
diff --git a/xen/include/asm-arm/domain.h
b/xen/include/asm-arm/domain.h
index 6819a3b..c235e5b 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -10,6
On 21.01.2021 09:00, Jürgen Groß wrote:
> On 21.01.21 08:55, Jan Beulich wrote:
>> On 20.01.2021 19:20, Julien Grall wrote:
>>> On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pass the function p
On 20.01.21 21:47, Stefano Stabellini wrote:
Hi Julien, Stefano
On Wed, 20 Jan 2021, Julien Grall wrote:
Hi Stefano,
On 20/01/2021 00:50, Stefano Stabellini wrote:
On Tue, 19 Jan 2021, Oleksandr wrote:
diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 40b9e59..0508bd8 100644
Fix compilation error when enabling early printk, introduced
by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
```
debug.S: Assembler messages:
debug.S:31: Error: constant expression expected at operand 2 -- `ldr
x15,=((0x0040+(0)*PAGE_SIZE)+(0x1c09&~PAGE_MASK))`
debug.S:38: Error: const
Hi Michal,
On 21/01/2021 09:30, Michal Orzel wrote:
Fix compilation error when enabling early printk, introduced
by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
```
debug.S: Assembler messages:
debug.S:31: Error: constant expression expected at operand 2 -- `ldr
x15,=((0x0040+(0)*PAGE_S
On 21.01.2021 10:30, Michal Orzel wrote:
> Fix compilation error when enabling early printk, introduced
> by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
> ```
> debug.S: Assembler messages:
> debug.S:31: Error: constant expression expected at operand 2 -- `ldr
> x15,=((0x0040+(0)*PAGE_SIZ
Hi Michal,
> On 21 Jan 2021, at 09:30, Michal Orzel wrote:
>
> Fix compilation error when enabling early printk, introduced
> by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
> ```
> debug.S: Assembler messages:
> debug.S:31: Error: constant expression expected at operand 2 -- `ldr
> x15,=((
Hi Jan,
On 21/01/2021 07:55, Jan Beulich wrote:
On 20.01.2021 19:20, Julien Grall wrote:
On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pass the function pointer via a
register (this needs to be done
On 20.01.21 02:23, Stefano Stabellini wrote:
Hi Stefano
On Sun, 17 Jan 2021, Oleksandr wrote:
On 15.01.21 02:55, Stefano Stabellini wrote:
On Tue, 12 Jan 2021, Oleksandr Tyshchenko wrote:
From: Julien Grall
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will impro
Hi Jan,
On 21.01.2021 10:43, Jan Beulich wrote:
> On 21.01.2021 10:30, Michal Orzel wrote:
>> Fix compilation error when enabling early printk, introduced
>> by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
>> ```
>> debug.S: Assembler messages:
>> debug.S:31: Error: constant expression expecte
Hi Jan,
On 21/01/2021 09:43, Jan Beulich wrote:
On 21.01.2021 10:30, Michal Orzel wrote:
Fix compilation error when enabling early printk, introduced
by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
```
debug.S: Assembler messages:
debug.S:31: Error: constant expression expected at operand 2
On 21.01.2021 10:50, Julien Grall wrote:
> Hi Jan,
>
> On 21/01/2021 07:55, Jan Beulich wrote:
>> On 20.01.2021 19:20, Julien Grall wrote:
>>> On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pas
On 20.01.21 18:21, Jan Beulich wrote:
Hi Jan
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
From: Julien Grall
As a lot of x86 code can be re-used on Arm later on, this patch
moves the IOREQ related dm-op handling to the common code.
The idea is to have the top level dm-op handling arch
On 21.01.2021 10:56, Julien Grall wrote:
> Hi Jan,
>
> On 21/01/2021 09:43, Jan Beulich wrote:
>> On 21.01.2021 10:30, Michal Orzel wrote:
>>> Fix compilation error when enabling early printk, introduced
>>> by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
>>> ```
>>> debug.S: Assembler message
On 21.01.2021 11:23, Oleksandr wrote:
> I would like to clarify regarding do_dm_op() which is identical for both
> arches and could *probably* be moved to the common code (we can return
> common dm.c back to put it there) and make dm_op() global.
> Would you/Paul be happy with that change? Or the
flight 158549 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158549/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-amd64
Hi,
I see a problem with destroy and restart of a domain. Interrupts are not
available when trying to restart a domain.
The situation seems very similar to the thread "null scheduler bug"
https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg01213.html.
The target system is a iMX8
On 21.01.21 12:27, Jan Beulich wrote:
Hi Jan
On 21.01.2021 11:23, Oleksandr wrote:
I would like to clarify regarding do_dm_op() which is identical for both
arches and could *probably* be moved to the common code (we can return
common dm.c back to put it there) and make dm_op() global.
Would
Acked-by: Christian Lindig
I am providing feedback on https://github.com/edwintorok/xen/pull/1.
In general: this is a large patch and therefore difficult to review for
correctness. However:
* It comes with a lot of testing and was fuzz-tested
* It improves building OCaml xenstore
* It improves
Acked-by: Christian Lindig
I'm providing some feedback on https://github.com/edwintorok/xen/pull/1
From: Edwin Török
Sent: 15 January 2021 22:28
To: xen-devel@lists.xenproject.org
Cc: Edwin Torok; Christian Lindig; David Scott; Ian Jackson; Wei Liu
Subje
Hi, Wei!
Wei, could you please review?
Regards,
Anastasiia Lukianenko
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch implements reference counting of foreign entries in
> in set_foreign_p2m_entry() on Arm. This is a mandatory action if
> we want to run emulator (IOREQ server) in other than dom0 domain,
> as we can't tru
On 18.01.2021 11:31, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Oleksandr Tyshchenko
>> Sent: 12 January 2021 21:52
>> To: xen-devel@lists.xenproject.org
>> Cc: Oleksandr Tyshchenko ; Jan Beulich
>> ; Andrew
>> Cooper ; Roger Pau Monné ;
>> Wei Liu ;
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-360
IRQ vector leak on x86
ISSUE DESCRIPTION
=
A x86 HVM guest with PCI pass through devices can force the allocation
of all IDT vectors on the system by rebooti
On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security team wrote:
> Xen Security Advisory XSA-360
>
> IRQ vector leak on x86
>
> ISSUE DESCRIPTION
> =
>
> A x86 HVM guest with PCI pass through devices can force the allocation
> of
On 21.01.2021 15:20, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security team wrote:
>> MITIGATION
>> ==
>>
>> Not running HVM guests with PCI pass through devices will avoid the
>> vulnerability. Note that even non-malicious guests can trigger th
On Thu, Jan 21, 2021 at 03:20:12PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security team wrote:
> > Xen Security Advisory XSA-360
> >
> > IRQ vector leak on x86
> >
> > ISSUE DESCRIPTION
> > =
On Tue, Jan 05, 2021 at 05:46:38PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> There are only two call-sites. One always sets it to 0 (which is unnecessary
> as the structure is already initialized to zero) and the other can simply set
> the 'vdevfn' field directly (after proper structure
On Tue, Jan 05, 2021 at 05:46:39PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and modify libxl_pci_bdf_assignable_add/remove/list() to make use of it.
>
> libxl_pci_bdf_assignable_add() will store the name of the device in xenstore
> if the field is specified (i.e. non-NULL) and
>
On Tue, Jan 05, 2021 at 05:46:40PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> With this patch applied 'xl pci-assignable-add' will take an optional '--name'
> parameter, 'xl pci-assignable-remove' can be passed either a BDF or a name and
> 'xl pci-assignable-list' will take a optional '-
On Tue, Jan 05, 2021 at 05:46:42PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch modifies libxlu_pci_parse_spec_string() to parse the new 'name'
> parameter of PCI_SPEC_STRING detailed in the updated documention in
> xl-pci-configuration(5) and populate the 'name' field of 'libxl
On 21.01.2021 15:34, Roger Pau Monné wrote:
> On Thu, Jan 21, 2021 at 03:20:12PM +0100, Marek Marczykowski-Górecki wrote:
>> On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security team wrote:
>>> Xen Security Advisory XSA-360
>>>
>>> IRQ vector leak o
On Wed, Jan 20, 2021 at 05:49:09PM -0500, Boris Ostrovsky wrote:
> This option allows guest administrator specify what should happen when
> guest accesses an MSR which is not explicitly emulated by the hypervisor.
>
> Signed-off-by: Boris Ostrovsky
> ---
> docs/man/xl.cfg.5.pod.in | 20 +
On Wed, Jan 20, 2021 at 05:49:12PM -0500, Boris Ostrovsky wrote:
> When creating a guest, if ignore_msrs option has been specified,
> apply it to guest's MSR policy.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Wei Liu
On Tue, Jan 19, 2021 at 04:15:25PM +0100, Jan Beulich wrote:
> This follows the logic used for other decompression methods utilizing an
> external library, albeit here we can't ignore the 32-bit size field
> appended to the compressed image - its presence causes decompression to
> fail. Leverage th
On Tue, Jan 19, 2021 at 04:15:53PM +0100, Jan Beulich wrote:
> The individual decompression CUs need to only surface their top level
> functions to other code. Arrange for everything else to be static, to
> make sure no undue uses of that code exist or will appear without
> explicitly noticing. (In
On Tue, Jan 19, 2021 at 04:16:35PM +0100, Jan Beulich wrote:
> Add a DOMPRINTF() other methods have, indicating success. To facilitate
> this, introduce an "outsize" local variable and update *size as well as
> *blob only once done. The latter then also avoids leaving a pointer to
> freed memory in
On Tue, Jan 19, 2021 at 04:16:53PM +0100, Jan Beulich wrote:
> The ones in xg_dom_decompress_unsafe.h suffice.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
On 21.01.2021 16:01, Wei Liu wrote:
> On Tue, Jan 19, 2021 at 04:15:25PM +0100, Jan Beulich wrote:
>> This follows the logic used for other decompression methods utilizing an
>> external library, albeit here we can't ignore the 32-bit size field
>> appended to the compressed image - its presence ca
On Thu, Jan 21, 2021 at 03:50:55PM +0100, Jan Beulich wrote:
> On 21.01.2021 15:34, Roger Pau Monné wrote:
> > On Thu, Jan 21, 2021 at 03:20:12PM +0100, Marek Marczykowski-Górecki wrote:
> >> On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security team wrote:
> >>> Xen Securi
On 21.01.2021 16:05, Roger Pau Monné wrote:
> On Thu, Jan 21, 2021 at 03:50:55PM +0100, Jan Beulich wrote:
>> On 21.01.2021 15:34, Roger Pau Monné wrote:
>>> On Thu, Jan 21, 2021 at 03:20:12PM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Jan 21, 2021 at 02:10:48PM +, Xen.org security t
On Thu, Jan 21, 2021 at 04:05:39PM +0100, Jan Beulich wrote:
> On 21.01.2021 16:01, Wei Liu wrote:
> > On Tue, Jan 19, 2021 at 04:15:25PM +0100, Jan Beulich wrote:
> >> This follows the logic used for other decompression methods utilizing an
> >> external library, albeit here we can't ignore the 32
On Tue, Jan 19, 2021 at 04:17:12PM +0100, Jan Beulich wrote:
> In all cases the kernel build makes available the uncompressed size in
> the final 4 bytes of the bzImage payload. Utilize this to avoid
> repeated realloc()ing of the output buffer.
>
> As a side effect this also addresses the previou
This follows the logic used for other decompression methods utilizing an
external library, albeit here we can't ignore the 32-bit size field
appended to the compressed image - its presence causes decompression to
fail. Leverage the field instead to allocate the output buffer in one
go, i.e. without
On 18.01.2021 12:55, Juergen Gross wrote:
> Add a HYPFS_VARDIR_INIT() macro for initializing such a directory
> statically, taking a struct hypfs_funcs pointer as parameter additional
> to those of HYPFS_DIR_INIT().
>
> Modify HYPFS_VARSIZE_INIT() to take the function vector pointer as an
> additi
On Wed, Jan 20, 2021 at 7:10 PM Robin Murphy wrote:
>
> On 2021-01-20 21:31, Rob Herring wrote:
> > On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy wrote:
> >>
> >> On 2021-01-20 16:53, Rob Herring wrote:
> >>> On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new c
On 18.01.2021 12:55, Juergen Gross wrote:
> Add some helpers to hypfs.c to support dynamic directories with a
> numerical id as name.
>
> The dynamic directory is based on a template specified by the user
> allowing to use specific access functions and having a predefined
> set of entries in the d
On 18.01.2021 12:55, Juergen Gross wrote:
> Add a "sched-gran" entry to the per-cpupool hypfs directories.
>
> For now make this entry read-only and let it contain one of the
> strings "cpu", "core" or "socket".
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 18.01.2021 12:55, Juergen Gross wrote:
> Make /cpupool//sched-gran in hypfs writable. This will enable per
> cpupool selectable scheduling granularity.
>
> Writing this node is allowed only with no cpu assigned to the cpupool.
> Allowed are values "cpu", "core" and "socket".
>
> Signed-off-by:
On 15.01.2021 15:28, Roger Pau Monne wrote:
> In vioapic_update_EOI the irq_lock will be dropped in order to forward
> the EOI to the dpci handler, so there's a window between clearing IRR
> and checking if the line is asserted where IRR can change behind our
> back.
>
> Fix this by checking wheth
flight 158550 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158550/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158542
test-amd64-amd64-xl-qemuu-win7-amd64
On 21.01.21 16:55, Jan Beulich wrote:
On 18.01.2021 12:55, Juergen Gross wrote:
Make /cpupool//sched-gran in hypfs writable. This will enable per
cpupool selectable scheduling granularity.
Writing this node is allowed only with no cpu assigned to the cpupool.
Allowed are values "cpu", "core" an
On 15.01.2021 15:28, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -268,6 +268,17 @@ static void vioapic_write_redirent(
>
> spin_unlock(&d->arch.hvm.irq_lock);
>
> +if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG &&
> + ent.fi
Hello Stefano,
> On 20 Jan 2021, at 8:31 pm, Stefano Stabellini wrote:
>
> On Wed, 20 Jan 2021, Rahul Singh wrote:
>> Add support for ARM architected SMMUv3 implementation. It is based on
>> the Linux SMMUv3 driver.
>>
>> Driver is currently supported as Tech Preview.
>>
>> Major differences w
Hello Oleksandr,
> On 20 Jan 2021, at 9:33 pm, Oleksandr wrote:
>
>
> On 20.01.21 16:52, Rahul Singh wrote:
>
> Hi Rahul
>
>> Add support for ARM architected SMMUv3 implementation. It is based on
>> the Linux SMMUv3 driver.
>>
>> Driver is currently supported as Tech Preview.
>>
>> Major di
On Mon, 2021-01-18 at 12:55 +0100, Juergen Gross wrote:
> Make /cpupool//sched-gran in hypfs writable. This will enable per
> cpupool selectable scheduling granularity.
>
> Writing this node is allowed only with no cpu assigned to the
> cpupool.
> Allowed are values "cpu", "core" and "socket".
>
On Thu, Jan 21, 2021 at 05:03:51PM +0100, Jan Beulich wrote:
> On 15.01.2021 15:28, Roger Pau Monne wrote:
> > In vioapic_update_EOI the irq_lock will be dropped in order to forward
> > the EOI to the dpci handler, so there's a window between clearing IRR
> > and checking if the line is asserted wh
On Mon, 2021-01-18 at 12:55 +0100, Juergen Gross wrote:
> Add a "sched-gran" entry to the per-cpupool hypfs directories.
>
> For now make this entry read-only and let it contain one of the
> strings "cpu", "core" or "socket".
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regar
On 2021-01-21 15:48, Rob Herring wrote:
On Wed, Jan 20, 2021 at 7:10 PM Robin Murphy
wrote:
On 2021-01-20 21:31, Rob Herring wrote:
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy
wrote:
On 2021-01-20 16:53, Rob Herring wrote:
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang
wrote:
I
On Thu, Jan 21, 2021 at 05:23:04PM +0100, Jan Beulich wrote:
> On 15.01.2021 15:28, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/vioapic.c
> > +++ b/xen/arch/x86/hvm/vioapic.c
> > @@ -268,6 +268,17 @@ static void vioapic_write_redirent(
> >
> > spin_unlock(&d->arch.hvm.irq_lock);
> >
flight 158559 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158559/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 21/01/2021 17:18, Rahul Singh wrote:
Hello Oleksandr,
Hi,
On 20 Jan 2021, at 9:33 pm, Oleksandr wrote:
On 20.01.21 16:52, Rahul Singh wrote:
Hi Rahul
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech
On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
> Hi,
>
Hello,
> I see a problem with destroy and restart of a domain. Interrupts are
> not
> available when trying to restart a domain.
>
> The situation seems very similar to the thread "null scheduler bug"
>
> https://lists.xenpro
On 21.01.21 15:57, Jan Beulich wrote:
Hi Jan
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch implements reference counting of foreign entries in
in set_foreign_p2m_entry() on Arm. This is a mandatory action if
we want to run emulator (IOREQ server) i
Hi Rahul,
Please try to trim the e-mail when quoting, otherwise it is quite
difficult to find the only couple of answer you wrote.
On 21/01/2021 17:10, Rahul Singh wrote:
On 20 Jan 2021, at 8:31 pm, Stefano Stabellini wrote:
-static void __iomem *arm_smmu_ioremap(struct device *dev, resourc
Hi Jan,
On 21/01/2021 10:24, Jan Beulich wrote:
On 21.01.2021 10:56, Julien Grall wrote:
Hi Jan,
On 21/01/2021 09:43, Jan Beulich wrote:
On 21.01.2021 10:30, Michal Orzel wrote:
Fix compilation error when enabling early printk, introduced
by commit aa4b9d1ee6538b5cbe218d4d3fcdf9548130a063:
`
Hello Julien,
> On 21 Jan 2021, at 6:31 pm, Julien Grall wrote:
>
> On 21/01/2021 17:18, Rahul Singh wrote:
>> Hello Oleksandr,
>
> Hi,
>
>>> On 20 Jan 2021, at 9:33 pm, Oleksandr wrote:
>>>
>>>
>>> On 20.01.21 16:52, Rahul Singh wrote:
>>>
>>> Hi Rahul
>>>
Add support for ARM archit
On 21/01/2021 10:54, Anders Törnqvist wrote:
Hi,
Hi Anders,
Thank you for reporting the bug. I am adding Stefano and Dario as IIRC
they were going to work on a solution.
Cheers,
I see a problem with destroy and restart of a domain. Interrupts are not
available when trying to restart a
Hi Dario,
On 21/01/2021 18:32, Dario Faggioli wrote:
On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
Hi,
I see a problem with destroy and restart of a domain. Interrupts are
not
available when trying to restart a domain.
The situation seems very similar to the thread "null scheduler
On 15.01.21 04:11, Stefano Stabellini wrote:
Hi Stefano
On Tue, 12 Jan 2021, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't explicitely remo
On 21/01/2021 18:50, Rahul Singh wrote:
Hello Julien,
On 21 Jan 2021, at 6:31 pm, Julien Grall wrote:
On 21/01/2021 17:18, Rahul Singh wrote:
Hello Oleksandr,
Hi,
On 20 Jan 2021, at 9:33 pm, Oleksandr wrote:
On 20.01.21 16:52, Rahul Singh wrote:
Hi Rahul
Add support for ARM arch
Hello Julien,
> On 21 Jan 2021, at 6:43 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> Please try to trim the e-mail when quoting, otherwise it is quite difficult
> to find the only couple of answer you wrote.
>
> On 21/01/2021 17:10, Rahul Singh wrote:
>>> On 20 Jan 2021, at 8:31 pm, Stefano Stab
flight 158552 linux-5.4 real [real]
flight 158562 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158552/
http://logs.test-lab.xenproject.org/osstest/logs/158562/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
Hi Volodymir,
On 20/01/2021 23:03, Volodymyr Babchuk wrote:
Julien Grall writes:
This is very interestingi too. Did you get any spikes with the
period
set to 100us? It would be fantastic if there were none.
3. Huge latency spike during domain creation. I conducted some
additional tests,
On Thu, 21 Jan 2021, Rahul Singh wrote:
> > On 21 Jan 2021, at 6:43 pm, Julien Grall wrote:
> > On 21/01/2021 17:10, Rahul Singh wrote:
> >>> On 20 Jan 2021, at 8:31 pm, Stefano Stabellini
> >>> wrote:
> -static void __iomem *arm_smmu_ioremap(struct device *dev,
> resource_size_t star
flight 158561 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158561/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 158553 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158553/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
From: Michał Leszczyński
Add an demonstration tool that uses xc_vmtrace_* calls in order
to manage external IPT monitoring for DomU.
Signed-off-by: Michał Leszczyński
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Michał Leszczyński
CC: Tamas K Lengyel
---
tools/misc/.gi
From: Michał Leszczyński
Add CPUID/MSR enumeration details for Processor Trace. For now, we will only
support its use inside VMX operation. Fill in the vmtrace_available boolean
to activate the newly introduced common infrastructure for allocating trace
buffers.
For now, Processor Trace is goi
From: Michał Leszczyński
To use vmtrace, buffers of a suitable size need allocating, and different
tasks will want different sizes.
Add a domain creation parameter, and audit it appropriately in the
{arch_,}sanitise_domain_config() functions.
For now, the x86 specific auditing is tuned to Proce
From: Michał Leszczyński
Allow to specify the size of per-vCPU trace buffer upon
domain creation. This is zero by default (meaning: not enabled).
Signed-off-by: Michał Leszczyński
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
CC: Michał Leszczyński
CC: Tam
From: Michał Leszczyński
Allow to map processor trace buffer using acquire_resource().
Signed-off-by: Michał Leszczyński
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Michał Leszczyński
CC: Tamas K Lengyel
v7:
* Rebase over changes elsewhere in the
From: Michał Leszczyński
Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface.
Signed-off-by: Michał Leszczyński
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Michał Leszczyński
CC: Tamas K Lengyel
v7:
* Use the name 'vmtrace' consistently.
---
tools/i
This is the next iteration of the external IPT monitoring series, reworked
massively from v6 to fix a whole slew of bugs with the XENMEM_acquire_resource
interface. It also includes some additional bugfixes to make traced VM's work
when forked.
A branch with all prerequisites is available at:
From: Michał Leszczyński
Implement an interface to configure and control tracing operations. Reuse the
existing SETDEBUGGING flask vector rather than inventing a new one.
Userspace using this interface is going to need platform specific knowledge
anyway to interpret the contents of the trace bu
We're about to introduce support for Intel Processor Trace, but similar
functionality exists in other platforms.
Aspects of vmtrace can reasonably can be common, so start with
XEN_SYSCTL_PHYSCAP_vmtrace and plumb the signal from Xen all the way down into
`xl info`.
Signed-off-by: Andrew Cooper
-
From: Tamas K Lengyel
Implement vmtrace_reset_pt function. Properly set IPT
state for VM forks.
Signed-off-by: Tamas K Lengyel
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
CC: Michał Leszczyński
CC: Tamas K Lengyel
v7:
On Thu, 21 Jan 2021, Oleksandr wrote:
> On 20.01.21 21:47, Stefano Stabellini wrote:
> > On Wed, 20 Jan 2021, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 20/01/2021 00:50, Stefano Stabellini wrote:
> > > > On Tue, 19 Jan 2021, Oleksandr wrote:
> > > > > diff --git a/xen/arch/arm/ioreq.c b
From: Tamas K Lengyel
Add pt_offset field to x86 regs in vm_event. Initialized to ~0 if PT
is not in use.
Signed-off-by: Tamas K Lengyel
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
CC: Michał Leszczyński
CC: Tamas K Len
On 1/21/21 9:56 AM, Wei Liu wrote:
> On Wed, Jan 20, 2021 at 05:49:09PM -0500, Boris Ostrovsky wrote:
>> This option allows guest administrator specify what should happen when
>> guest accesses an MSR which is not explicitly emulated by the hypervisor.
>>
>> Signed-off-by: Boris Ostrovsky
>> --
flight 158555 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158555/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b4a97bbc39ed8e7eb50038b9cffe2e948e49995
baseline version:
ovmf 339371ef78eb3a6f2e984
On Thu, 2021-01-21 at 19:40 +, Julien Grall wrote:
> Hi Dario,
>
Hi!
> On 21/01/2021 18:32, Dario Faggioli wrote:
> > On Thu, 2021-01-21 at 11:54 +0100, Anders Törnqvist wrote:
> > >
> > > https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg01213.html
> > > .
> > >
> > Right.
flight 158565 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158565/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
This is version 3 for a patch set sent out to the ML in 2018 [1] to
support UEFI Secure Boot for Xen on multiboot2 platforms.
A new binary, xen.mb.efi, is built. It contains the mb2 header as well
as a hand-crafted PE/COFF header. The dom0 kernel is verified using the
shim lock protocol.
I foll
From: Daniel Kiper
POSIX time is required to fill the TimeDateStamp field
in the PE header.
Use SOURCE_DATE_EPOCH if available, otherwise use
`date +%s` (available on both Linux and FreeBSD).
Signed-off-by: Daniel Kiper
Signed-off-by: Bobby Eshleman
---
xen/Makefile | 2 ++
x
From: Daniel Kiper
In comparison to ELF the PE format is not supported by the Multiboot
protocol. So, if we wish to load xen.mb.efi using this protocol we
have to put header_addr, load_addr, load_end_addr, bss_end_addr and
entry_addr data into Multiboot header.
The Multiboot protocol spec can be
From: Daniel Kiper
This patch introduces xen.mb.efi which contains a manually built PE
header.
This allows us to support Xen on UEFI Secure Boot-enabled hosts via
multiboot2.
xen.mb.efi is a single binary that is loadable by a UEFI loader or via
the Multiboot/Multiboot2 protocols.
Signed-off-b
From: Daniel Kiper
In comparison to ELF the PE format is not supported by the Multiboot2
protocol. So, if we wish to load xen.mb.efi using this protocol we have
to add MULTIBOOT2_HEADER_TAG_ADDRESS and MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS
tags into Multiboot2 header.
Additionally, put MULTIBOOT2_
1 - 100 of 103 matches
Mail list logo
