On 15.06.2020 21:27, Tamas K Lengyel wrote:
> On Tue, Jun 2, 2020 at 3:39 AM Jan Beulich wrote:
>>
>> On 02.06.2020 09:37, Paul Durrant wrote:
>>> Maintainers/committers, can we please get those patches in a.s.a.p.?
>>
>> The sole reason I didn't put in at least the 1st patch on Friday
>> (perhaps
On 16.06.2020 03:00, Stefano Stabellini wrote:
> On Sat, 13 Jun 2020, Julien Grall wrote:
>> From: Julien Grall
>>
>> The documentation of pvcalls suggests there is padding for 32-bit x86
>> at the end of most the structure. However, they are not described in
>> in the public header.
>>
>> Because
flight 151140 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 150040
build-i386-pre
On 12.06.2020 19:32, Andrew Cooper wrote:
> xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to
> free() seeing as it discards the results.
>
> This is logically a backport of c/s b91825f628 "tools/libxc: Drop
> config_transformed parameter from xc_cpuid_set()" but rewritte
> On 15 Jun 2020, at 22:32, Stefano Stabellini wrote:
>
> On Mon, 15 Jun 2020, CodeWiz2280 wrote:
>> On Wed, Jun 10, 2020 at 5:46 PM Julien Grall
>> wrote:
>>>
>>> Hi Marc,
>>>
>>> On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote:
> I was wondering if you heard about any potential issu
Hi Richard,
+ Julien and Stefano
> On 15 Jun 2020, at 23:29, Richard Simpson wrote:
>
> Hello,
>
> Just to report that I have successfully installed Xen on a Pine RockPro64 ARM
> SBC.
Very nice :-)
>
> I am using Xen 4.13 booting directly from u-boot on an SD card and my dom0
> distributi
On 14.06.2020 16:36, Grzegorz Uriasz wrote:
> --- a/xen/arch/x86/acpi/boot.c
> +++ b/xen/arch/x86/acpi/boot.c
> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct
> acpi_table_header *table)
> if (fadt->xpm_timer_block.space_id ==
> ACPI_ADR_SPACE_SYSTEM_
On 2020-06-15 20:14, CodeWiz2280 wrote:
[...]
Also, the latest linux kernel still has the X-Gene storm distributor
address as "0x7801" in the device tree, which is what the Xen code
considers a match with the old firmware. What were the addresses for
the device tree supposed to be changed
On Tue, Jun 16, 2020 at 08:11:12AM +0200, Jan Beulich wrote:
> On 10.06.2020 16:29, Roger Pau Monne wrote:
> > @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi)
> > * to know if the GSI is pending or not.
> > */
> > spin_lock(&d->arch.hvm.irq_lock);
> > -
On 13.06.2020 20:41, Julien Grall wrote:
> @@ -73,10 +76,18 @@ struct xen_pvcalls_request {
> uint32_t flags;
> grant_ref_t ref;
> uint32_t evtchn;
> +#ifndef __i386__
> +uint8_t pad[4];
> +#endif
Where possible I think uint32_t would be slightly
On 01.06.2020 15:21, Tamas K Lengyel wrote:
> Tamas K Lengyel (13):
> x86/mem_sharing: block interrupt injection for forks
> tools/libxc: xc_memshr_fork with interrupts blocked
I've committed these two, and I'll leave the rest to the tool stack
maintainers.
Jan
Dear Bertrand,
Just to confirm that the Linux distro is Gentoo. I know it's not very
common these days, but I have used it for very many years and it is what
I am used to.
Gentoo has a xen package but only for arm32 and then masked as unstable
so I just grabbed 4.13 via git. It also has a
On Tue, Jun 16, 2020 at 08:27:54AM +0200, Jan Beulich wrote:
> On 10.06.2020 16:29, Roger Pau Monne wrote:
> > @@ -558,6 +559,12 @@ int pt_irq_create_bind(
> > */
> > ASSERT(!mask);
> > share = trigger_mode;
> > +if
On 16.06.2020 10:37, Roger Pau Monné wrote:
> On Tue, Jun 16, 2020 at 08:27:54AM +0200, Jan Beulich wrote:
>> On 10.06.2020 16:29, Roger Pau Monne wrote:
>>> @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct
>>> hvm_pirq_dpci *pirq_dpci)
>>> if ( pirq_dpci->flags &
On 15.06.2020 16:15, Andrew Cooper wrote:
> The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're
> about to start relying on this. Extend the unit tests.
>
> As test_cpuid_serialise_success() is a fairly limited set of synthetic
> examples right now, introduce test_cpuid
On 15.06.2020 16:15, Andrew Cooper wrote:
> Currently, libxl__cpuid_legacy() passes each element of the policy list to
> xc_cpuid_set() individually. This is wasteful both in terms of the number of
> hypercalls made, and the quantity of repeated merging/auditing work performed
> by Xen.
>
> Move
On 16/06/2020 09:26, Jan Beulich wrote:
On 13.06.2020 20:41, Julien Grall wrote:
@@ -73,10 +76,18 @@ struct xen_pvcalls_request {
uint32_t flags;
grant_ref_t ref;
uint32_t evtchn;
+#ifndef __i386__
+uint8_t pad[4];
+#endif
Where possible
On Tue, Jun 16, 2020 at 10:45:51AM +0200, Jan Beulich wrote:
> On 16.06.2020 10:37, Roger Pau Monné wrote:
> > On Tue, Jun 16, 2020 at 08:27:54AM +0200, Jan Beulich wrote:
> >> On 10.06.2020 16:29, Roger Pau Monne wrote:
> >>> @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct
On 15.06.2020 16:15, Andrew Cooper wrote:
> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> domid, bool restore,
> goto out;
> }
>
> +/*
> + * Account for feature which have been disabled by default since Xen
> 4.13,
> + * so migrated-in VM
On 16.06.2020 11:19, Julien Grall wrote:
>
>
> On 16/06/2020 09:26, Jan Beulich wrote:
>> On 13.06.2020 20:41, Julien Grall wrote:
>>> @@ -73,10 +76,18 @@ struct xen_pvcalls_request {
>>> uint32_t flags;
>>> grant_ref_t ref;
>>> uint32_t evtchn;
>>> +#ifn
Hi,
On 16/06/2020 02:00, Stefano Stabellini wrote:
On Sat, 13 Jun 2020, Julien Grall wrote:
From: Julien Grall
The documentation of pvcalls suggests there is padding for 32-bit x86
at the end of most the structure. However, they are not described in
in the public header.
Because of that all
On 15.06.2020 16:15, Andrew Cooper wrote:
> This was an accidental asymmetry with the HVM side.
>
> No change in behaviour at this point.
>
> Fixes: 83b387382 ("x86/cpuid: Introduce and use default CPUID policies")
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with a remark:
> --- a
On 16/06/2020 10:36, Jan Beulich wrote:
On 16.06.2020 11:19, Julien Grall wrote:
On 16/06/2020 09:26, Jan Beulich wrote:
On 13.06.2020 20:41, Julien Grall wrote:
@@ -73,10 +76,18 @@ struct xen_pvcalls_request {
uint32_t flags;
grant_ref_t ref;
On 15.06.2020 16:15, Andrew Cooper wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -512,11 +512,21 @@ The Speculation Control hardware features `srbds-ctrl`,
> `md-clear`, `ibrsb`,
> `stibp`, `ibpb`, `l1d-flush` and `ssbd` are used by default if ava
On 12.06.2020 02:22, Volodymyr Babchuk wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1895,6 +1895,7 @@ void do_IRQ(struct cpu_user_regs *regs)
> int irq = this_cpu(vector_irq)[vector];
> struct cpu_user_regs *old_regs = set_irq_regs(regs);
>
> +vcp
On 12.06.2020 02:22, Volodymyr Babchuk wrote:
> In most cases hypervisor code performs guest-related jobs. Tasks like
> hypercall handling or MMIO access emulation are done for calling vCPU
> so it is okay to charge time spent in hypervisor to the current vCPU.
>
> But, there are also tasks that a
Hi,
On 16/06/2020 09:03, Bertrand Marquis wrote:
Hi Richard,
+ Julien and Stefano
On 15 Jun 2020, at 23:29, Richard Simpson wrote:
Hello,
Just to report that I have successfully installed Xen on a Pine RockPro64 ARM
SBC.
Very nice :-)
I am using Xen 4.13 booting directly from u-boot
In order to avoid relying on the specific values of
VIOAPIC_{LEVEL/EDGE}_TRIG.
No functional change.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm
Hello,
On 16/06/2020 09:33, Richard Simpson wrote:
I would be happy to try to report my success via the smoke test page
(https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results) if
I can figure out how. Strangely, I can't see anything listed under
"Test Results" from anyone else.
On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote:
> On 14.06.2020 16:36, Grzegorz Uriasz wrote:
> > --- a/xen/arch/x86/acpi/boot.c
> > +++ b/xen/arch/x86/acpi/boot.c
> > @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct
> > acpi_table_header *table)
> > if (fadt-
Forgot to add maintainers.
On Tue, Jun 16, 2020 at 12:20:56PM +0200, Roger Pau Monne wrote:
> In order to avoid relying on the specific values of
> VIOAPIC_{LEVEL/EDGE}_TRIG.
>
> No functional change.
>
> Requested-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/hvm/irq.
On 16.06.2020 12:20, Roger Pau Monne wrote:
> In order to avoid relying on the specific values of
> VIOAPIC_{LEVEL/EDGE}_TRIG.
>
> No functional change.
>
> Requested-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Since the other patch went in, also Cc-ing Paul for
Otherwise it's impossible to know the reason for a fault or blob rejection
inside the automation.
While at it, also change return code of incorrect invokation to EINVAL.
Signed-off-by: Igor Druzhinin
---
Changes in v2:
- simply call "return errno". On Linux that seems to be safe as values <=255
> -Original Message-
> From: Jan Beulich
> Sent: 16 June 2020 12:22
> To: Roger Pau Monne
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Andrew Cooper
> ;
> Paul Durrant
> Subject: Re: [PATCH] x86/hvm: check against VIOAPIC_LEVEL_TRIG in
> hvm_gsi_deassert
>
> On 16.06.2020 12:20, Ro
flight 151167 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151167/
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 1
Due to the re-scheduling of the XenSummit from June to July, as well as making
it a virtual event covering a few more days, we have space to accept more talks.
Rather than going through the entire submission process again, we’ve decided to
utilize the design session website. If you wish to give
On 16.06.2020 13:42, Igor Druzhinin wrote:
> @@ -62,8 +62,11 @@ int main(int argc, char *argv[])
>
> ret = xc_microcode_update(xch, buf, len);
> if ( ret )
> +{
> fprintf(stderr, "Failed to update microcode. (err: %s)\n",
> strerror(errno));
> +retu
On 16.06.2020 12:32, Roger Pau Monné wrote:
> On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote:
>> On 14.06.2020 16:36, Grzegorz Uriasz wrote:
>>> --- a/xen/arch/x86/acpi/boot.c
>>> +++ b/xen/arch/x86/acpi/boot.c
>>> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct
>>> acpi
On 16/06/2020 13:25, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 16.06.2020 13:42, Igor Druzhinin wrote:
>> @@ -62,8 +62,11 @@ int main(int argc, char *argv[])
>>
>>
On Tue, Jun 16, 2020 at 2:32 AM Jan Beulich wrote:
>
> On 01.06.2020 15:21, Tamas K Lengyel wrote:
> > Tamas K Lengyel (13):
> > x86/mem_sharing: block interrupt injection for forks
> > tools/libxc: xc_memshr_fork with interrupts blocked
>
> I've committed these two, and I'll leave the rest to
On 16.06.2020 12:32, Roger Pau Monné wrote:
> On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote:
>> On 14.06.2020 16:36, Grzegorz Uriasz wrote:
>>> --- a/xen/arch/x86/acpi/boot.c
>>> +++ b/xen/arch/x86/acpi/boot.c
>>> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct
>>> acpi
On 09.06.2020 17:44, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 09 June 2020 16:33
>>
>> On 09.06.2020 17:28, Paul Durrant wrote:
From: Jan Beulich
Sent: 09 June 2020 16:08
On 08.06.2020 13:04, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 08 June 2020 11:5
flight 151148 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151016
Tests which did no
On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote:
> On 16.06.2020 12:32, Roger Pau Monné wrote:
> > On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote:
> >> On 14.06.2020 16:36, Grzegorz Uriasz wrote:
> >>> --- a/xen/arch/x86/acpi/boot.c
> >>> +++ b/xen/arch/x86/acpi/boot.c
> >>
I'm wondering why support for 32 bit acpi pm timers was introduced to xen.
Linux doesn't bother and just crops it to 24 bits:
https://github.com/torvalds/linux/blob/a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55/drivers/clocksource/acpi_pm.c#L37
Best regards,
Grzegorz Uriasz
On 16/06/2020 16:59, Roger
On 16.06.2020 16:59, Roger Pau Monné wrote:
> On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote:
>> --- unstable.orig/xen/arch/x86/acpi/boot.c
>> +++ unstable/xen/arch/x86/acpi/boot.c
>> @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct
>> if (fadt->header.revision >= FADT
Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re:
[xen-4.10-testing test] 151033: regressions - trouble:
blocked/fail/pass/starved) [and 1 more messages]"):
> Right - which will then enable 4.10's -prev build to work, which
> will in turn allow 4.11's -prev builds to work, and then
On 16.06.2020 17:10, Grzegorz Uriasz wrote:
> I'm wondering why support for 32 bit acpi pm timers was introduced to xen.
The handling of the timer wrapping is less overhead is a wider timer can
be used.
Jan
Intel Processor Trace is an architectural extension available in modern Intel
family CPUs. It allows recording the detailed trace of activity while the
processor executes the code. One might use the recorded trace to reconstruct
the code flow. It means, to find out the executed code paths, deter
Define constants related to Intel Processor Trace features.
Signed-off-by: Michal Leszczynski
---
xen/include/asm-x86/msr-index.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index b328a47
Check if Intel Processor Trace feature is supported by current
processor. Define hvm_ipt_supported function.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmx.c | 24 +
xen/include/asm-x86/cpufeature.h| 1 +
xen/include/asm-x86/hvm/h
Guest IPT state will be preserved across vmentry/vmexit using
this structure.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmx.c | 2 ++
xen/include/asm-x86/hvm/vmx/vmcs.h | 10 ++
2 files changed, 12 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arc
Provide an interface for privileged domains to manage
external IPT monitoring.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/hvm.c | 170
xen/include/public/hvm/hvm_op.h | 27 +
2 files changed, 197 insertions(+)
diff --git a/xen/arch/x86/
Add functions in libxc that use the new HVMOP_vmtrace interface.
Signed-off-by: Michal Leszczynski
---
tools/libxc/include/xenctrl.h | 59 +++
tools/libxc/xc_tbuf.c | 108 ++
2 files changed, 167 insertions(+)
diff --git a/tools/libxc/inc
Add an demonstration tool that uses xc_ptbuf_* calls in order
to manage external IPT monitoring for DomU.
Signed-off-by: Michal Leszczynski
---
tools/proctrace/COPYING | 339
tools/proctrace/Makefile| 49 ++
tools/proctrace/proctrace.c | 139
Enable IPT when entering the VM and disable it on vmexit.
Register state is persisted using vCPU ipt_state structure.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmx.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/
On Tue, Jun 16, 2020 at 05:11:58PM +0200, Jan Beulich wrote:
> On 16.06.2020 16:59, Roger Pau Monné wrote:
> > On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote:
> >> --- unstable.orig/xen/arch/x86/acpi/boot.c
> >> +++ unstable/xen/arch/x86/acpi/boot.c
> >> @@ -480,7 +480,9 @@ static int
On 16/06/2020 10:16, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> Currently, libxl__cpuid_legacy() passes each element of the policy list to
>> xc_cpuid_set() individually. This is wasteful both in terms of the number of
>> hypercalls made, and the quantity of repeated merging
Am 29.05.2020 um 00:55 hat Roman Kagan geschrieben:
> BlockConf includes several properties counted in bytes.
>
> Enhance their handling in some aspects, specifically
>
> - accept common size suffixes (k, m)
> - perform consistency checks on the values
> - lift the upper limit on physical_block_s
On 16/06/2020 10:33, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
>> domid, bool restore,
>> goto out;
>> }
>>
>> +/*
>> + * Account for feature which have been disabled by defau
On 16/06/2020 10:40, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> This was an accidental asymmetry with the HVM side.
>>
>> No change in behaviour at this point.
>>
>> Fixes: 83b387382 ("x86/cpuid: Introduce and use default CPUID policies")
>> Signed-off-by: Andrew Cooper
> Re
On 16/06/2020 11:00, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -512,11 +512,21 @@ The Speculation Control hardware features
>> `srbds-ctrl`, `md-clear`, `ibrsb`,
>> `stibp`, `ibpb`, `l
On Tue, Jun 16, 2020 at 05:20:39PM +0200, Michał Leszczyński wrote:
> Check if Intel Processor Trace feature is supported by current
> processor. Define hvm_ipt_supported function.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 24
On Tue, Jun 16, 2020 at 05:21:20PM +0200, Michał Leszczyński wrote:
> Guest IPT state will be preserved across vmentry/vmexit using
> this structure.
I think you should squash this patch with a patch where the structure
it's actually used.
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x8
Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing
test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> I propose to update in
> http://xenbits.xen.org/gitweb/?p=libvirt.git;a=summary
> the refs
> refs/heads/osstest/frozen/xen-4.10-testing
> refs/he
This looks like this was once a call to test(1). ssh-add, as it
happens, seems to ignore this spuriuous `]' (!) so there isn't any
significant change.
Signed-off-by: Ian Jackson
---
standalone | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/standalone b/standalone
index 977a
In this case, there is no need to ssh anywhere.
No change other than in dev-debugging setups.
Signed-off-by: Ian Jackson
---
standalone | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/standalone b/standalone
index b51acf7b..9553d6c9 100755
--- a/standalone
+++ b/standalone
@
Otherwise if logs doesn't exist, the code in `standalone' which is
eventually called to build each flight will try to do it - but that
code is not idempotent in the presence of other racing copies of
itself.
Rather than trusting mkdir -p there, do it here.
No change other than to this dev-debuggi
Xen 4.9 doesn't build on buster and won't be fixed for that.
Xen 4.10's "-prev" migration tests also fail for the same reason.
There is a (smallish) risk that Debian will break stretch before Xen
4.10 goes completely out of support from the Xen Project. If that
happens we could revert this - but
On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote:
> Provide an interface for privileged domains to manage
> external IPT monitoring.
>
> Signed-off-by: Michal Leszczynski
Thanks for the patch! I have some questions below which require your
input.
> ---
> xen/arch/x86/hvm/hvm.
On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wrote:
> Enable IPT when entering the VM and disable it on vmexit.
> Register state is persisted using vCPU ipt_state structure.
Shouldn't this be better done using Intel MSR load lists?
That seems to be what the SDM recommends for trac
- 16 cze 2020 o 19:38, Roger Pau Monné roger@citrix.com napisał(a):
> On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wrote:
>> Enable IPT when entering the VM and disable it on vmexit.
>> Register state is persisted using vCPU ipt_state structure.
>
> Shouldn't this be bette
From: Julien Grall
SMC call will update some of registers (typically only x0) depending on
the arguments provided.
Some CPUs can speculate past a SMC instruction and potentially perform
speculative access to emrmoy using the pre-call values before executing
the SMC.
There is no known gadget ava
From: Julien Grall
Hi all,
Arm recently released a whitepaper about a new category of speculation.
(see [1] and [2]). In short, a processor may be able to speculate past
some of the unconditional control flow instructions (e.g eret, smc, br).
In some of the cases, the registers will contain val
From: Julien Grall
Some CPUs can speculate past a RET instruction and potentially perform
speculative accesses to memory before processing the return.
There is no known gadget available after the RET instruction today.
However some of the registers (such as in check_pending_guest_serror())
may c
On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote:
>
> On 2020-06-15 20:14, CodeWiz2280 wrote:
>
> [...]
>
> > Also, the latest linux kernel still has the X-Gene storm distributor
> > address as "0x7801" in the device tree, which is what the Xen code
> > considers a match with the old firmwar
On 16/06/2020 16:16, Michał Leszczyński wrote:
> Intel Processor Trace is an architectural extension available in modern Intel
> family CPUs. It allows recording the detailed trace of activity while the
> processor executes the code. One might use the recorded trace to reconstruct
> the code flo
On 2020-06-16 19:13, CodeWiz2280 wrote:
On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote:
On 2020-06-15 20:14, CodeWiz2280 wrote:
[...]
> Also, the latest linux kernel still has the X-Gene storm distributor
> address as "0x7801" in the device tree, which is what the Xen code
> consider
- 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@citrix.com napisał(a):
> On 16/06/2020 16:16, Michał Leszczyński wrote:
>> Intel Processor Trace is an architectural extension available in modern Intel
>> family CPUs. It allows recording the detailed trace of activity while the
>> processor
While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been
observed due to a mm-lock order violation while copying the HVM CPU context
from the parent. This issue has been identified to be due to
hap_update_paging_modes getting a lock on the gfn using get_gfn. This call also
creat
flight 151149 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065
test-amd64-amd64-
On Mon, 15 Jun 2020, Bobby Eshleman wrote:
> On Tue, Jun 16, 2020 at 01:10:17AM +, Alistair Francis wrote:
> > On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote:
> > > Any updates? I am looking forward to this :-)
> >
>
> It has been on a slow burn since I became a new dad (shortly
On 16/06/2020 19:47, Michał Leszczyński wrote:
> - 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@citrix.com napisał(a):
>
>> Are there any restrictions on EPT being enabled in the first place? I'm
>> not aware of any, and in principle we could use this functionality for
>> PV guests as wel
On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote:
>
> Am Wed, 10 Jun 2020 20:16:57 +0100
> schrieb Tim Deegan :
>
> > How tedious.
>
> Indeed. This compiles for me as well:
just a nudge on this; it would be nice to get a patch into the tree
since the build failure affects master builds of Xen i
On Tue, 16 Jun 2020, Julien Grall wrote:
> On 16/06/2020 02:00, Stefano Stabellini wrote:
> > On Sat, 13 Jun 2020, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > The documentation of pvcalls suggests there is padding for 32-bit x86
> > > at the end of most the structure. However, they a
On Tue, 16 Jun 2020, Julien Grall wrote:
> From: Julien Grall
>
> Some CPUs can speculate past a RET instruction and potentially perform
> speculative accesses to memory before processing the return.
>
> There is no known gadget available after the RET instruction today.
> However some of the re
On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini wrote:
>
> On Tue, 16 Jun 2020, Julien Grall wrote:
> > On 16/06/2020 02:00, Stefano Stabellini wrote:
> > > On Sat, 13 Jun 2020, Julien Grall wrote:
> > > > From: Julien Grall
> > > >
> > > > The documentation of pvcalls suggests there is padding
On Tue, 16 Jun 2020, Julien Grall wrote:
> From: Julien Grall
>
> SMC call will update some of registers (typically only x0) depending on
^a SMC call
> the arguments provided.
>
> Some CPUs can speculate past a SMC instruction and potentially perform
> speculative access to emrmoy using the p
On Tue, 16 Jun 2020 at 22:34, Stefano Stabellini wrote:
>
> On Tue, 16 Jun 2020, Julien Grall wrote:
> > From: Julien Grall
> >
> > SMC call will update some of registers (typically only x0) depending on
> ^a SMC call
>
> > the arguments provided.
> >
> > Some CPUs can speculate past a SMC inst
On 16/06/2020 22:57, Julien Grall wrote:
> On Tue, 16 Jun 2020 at 22:34, Stefano Stabellini
> wrote:
>> On Tue, 16 Jun 2020, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> SMC call will update some of registers (typically only x0) depending on
>> ^a SMC call
An SMC call.
>>
>>> the argum
flight 151153 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151153/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13
On Wed, 17 Jun 2020, Andrew Cooper wrote:
> On 16/06/2020 22:57, Julien Grall wrote:
> > On Tue, 16 Jun 2020 at 22:34, Stefano Stabellini
> > wrote:
> >> On Tue, 16 Jun 2020, Julien Grall wrote:
> >>> From: Julien Grall
> >>>
> >>> SMC call will update some of registers (typically only x0) depen
+Luwei, who developed PT for KVM and is the best one who can help
review VMX changes from Intel side. Please include him in future
post or discussion.
> -Original Message-
> From: Michał Leszczyński
> Sent: Wednesday, June 17, 2020 2:48 AM
> To: Andrew Cooper
> Cc: Xen-devel ; Jan Beulic
Otherwise it's difficult to know if operation failed inside the automation.
While at it, also switch to returning 1 and 2 instead of errno to avoid
incompatibilies between errno and special exit code numbers.
Signed-off-by: Igor Druzhinin
---
Changes in v3:
- conventionally return 1 and 2 instea
`xl shutdown -w` waits for the first of either domain shutdown or death.
Shutdown is the halting of the guest operating system, and death is the
freeing of domain resources.
Allow specifying -w multiple times to wait for only domain death. This
is useful in scripts so that all resources are free
On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote:
>
> On 16/06/2020 19:47, Michał Leszczyński wrote:
> > - 16 cze 2020 o 20:17, Andrew Cooper andrew.coop...@citrix.com
> > napisał(a):
> >
> >> Are there any restrictions on EPT being enabled in the first place? I'm
> >> not aware of any, a
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
On 16/06/2020 19:42, Laszlo Ersek wrote
> If I understand correctly, TimerInterruptHandler()
> [OvmfPkg/8254TimerDxe/Timer.c] currently does the following:
>
> - RaiseTPL (TPL_HIGH_LEVEL) --> mask interrupts from being delivered
>
> - mLegacy8259->EndOfInterrupt() --> permit the PIC to generate f
flight 151155 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151155/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151118
test-amd64-amd64-xl-qemuu-win7-amd64
Code compiled with gcc10 will not link properly due to multiple definition of
the same function.
Signed-off-by: Olaf Hering
---
stubdom/Makefile | 1 +
stubdom/vtpm_extern.patch | 48 +++
2 files changed, 49 insertions(+)
create mode 100644 stubdom
1 - 100 of 102 matches
Mail list logo
