On Sun, Jun 14, 2020 at 02:36:28PM +, Grzegorz Uriasz wrote:
> On some computers the bit width of the PM Timer as reported
> by ACPI is 32 bits when in fact the FADT flags report correctly
> that the timer is 24 bits wide. On affected machines such as the
> ASUS FX504GM and never gaming laptops
> -Original Message-
> From: Julien Grall
> Sent: 13 June 2020 19:42
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Julien Grall ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Julien Grall ; Stefano Stabellini
> ; Wei
> Liu ; Juergen Gross
> Subject: [P
flight 151095 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151095/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 151016
test-arm64-arm64-li
osstest service owner writes ("[xen-unstable test] 151073: regressions - FAIL"):
> flight 151073 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/151073/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> t
> -Original Message-
> From: Roger Pau Monne
> Sent: 12 June 2020 16:57
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu
> Subject: [PATCH for-4.14 1/8] x86/hvm: fix vIO-APIC build without
> IRQ0_SPECIAL_ROUTING
>
> pi
On Sun, Jun 14, 2020 at 10:12:03PM +, Grzegorz Uriasz wrote:
> When passing through a IGD VGA device qemu needs to copy the host VBIOS
> to the target domain. Right now the current implementation on the qemu side
> is one big undefined behavior as described in my qemu patchset here:
> https://p
Paul Durrant writes ("RE: [XEN PATCH for-4.14] tools/xen-ucode: fix error code
propagation of microcode load operation"):
> > -Original Message-
> > From: Ian Jackson
> > Paul, would you Release-ack a patch that replaced every `return errno'
> > with (say) exit(12) ?
>
> Why 12?
I tend
Igor Druzhinin writes ("Re: [XEN PATCH for-4.14] tools/xen-ucode: fix error
code propagation of microcode load operation"):
> On 12/06/2020 17:53, Ian Jackson wrote:
> > Unfortunately I don't think this is right. errno might not fit into a
> > return value.
>
> errno codes that Xen return are al
On Sun, Jun 14, 2020 at 10:12:01PM +, Grzegorz Uriasz wrote:
> When qemu is running inside a linux based stubdomain, qemu does not
> have the necessary permissions to map the ioports to the target domain.
> Currently, libxl is granting permissions only for the VGA RAM memory region
> and not pa
Grzegorz Uriasz writes ("[PATCH 1/3] tools/libxl: Grant VGA IO port permission
for stubdom/target domain"):
> When qemu is running inside a linux based stubdomain, qemu does not
> have the necessary permissions to map the ioports to the target domain.
> Currently, libxl is granting permissions onl
> On Jun 12, 2020, at 3:31 PM, Nick Rosbrook wrote:
>
> Currently, no minimum go compiler version is required by the configure
> scripts. However, the go bindings actually will not build with some
> older versions of go. Add a check for a minimum go version of 1.11.1 in
> accordance with tools/g
On Mon, Jun 15, 2020 at 11:00:38AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 12 June 2020 16:57
> > To: xen-devel@lists.xenproject.org
> > Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> > ; Andrew
> > Cooper ; Wei Liu
> > Subject: [PATCH for
On Sun, Jun 14, 2020 at 10:12:02PM +, Grzegorz Uriasz wrote:
> IGD VGA devices require a special opregion MMIO region which functions as
> an extra BAR in the PCI configuration space. Right now qemu is assigning those
> permissions - this is failing inside a linux based stubdomain as the
> stub
On Sun, Jun 14, 2020 at 11:21:09PM +, Grzegorz Uriasz wrote:
> With the upstreaming of linux based stubdomains to xen, qemu can't
> assume it runs inside dom0 - permission assignment must be moved to
> libxl running in dom0. This xen patch:
> https://lists.xenproject.org/archives/html/xen-devel
flight 151101 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151101/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 151065
test-amd64-amd64-
On 12.06.2020 18:47, Ian Jackson wrote:
> Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing
> test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
>>> test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs.
>>> 150039
>>> test-amd64-amd6
Andrew Cooper writes ("Re: Xen 4.10 breakage with buster (was Re:
[xen-4.10-testing test] 151033: regressions - trouble:
blocked/fail/pass/starved)"):
> On 12/06/2020 17:47, Ian Jackson wrote:
> > Ian Jackson writes ("Xen 4.10 breakage with buster (was Re:
> > [xen-4.10-testing test] 151033: reg
Nick Rosbrook writes ("Re: [PATCH for-4.14] tools: check go compiler version if
present"):
> On Fri, Jun 12, 2020 at 05:40:21PM +0100, Ian Jackson wrote:
> > Nick Rosbrook writes ("[PATCH for-4.14] tools: check go compiler version if
> > present"):
> > > Currently, no minimum go compiler version
Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing
test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> osstest service owner writes ("[xen-4.10-testing test] 151033: regressions -
> trouble: blocked/fail/pass/starved"):
> > flight 151033 xen-4.10-testin
> On 12 Jun 2020, at 21:31, Julien Grall wrote:
>
>
>
> On 12/06/2020 17:51, Bertrand Marquis wrote:
>
> Hi,
>
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 4e2f582006..3a7f53e13d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/inclu
On 15.06.2020 15:44, Ian Jackson wrote:
> Thanks to both for your opinions. I have pushed those two to 4.10 and
> will see how things go. I may send them to 4.9 too.
Won't 4.10 continue to be blocked then because or -prev issues?
Jan
Paul Durrant writes ("RE: [PATCH] tools/libxengnttab: correct size of allocated
memory"):
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Jürgen Groß
> > Sent: 11 June 2020 16:26
> > To: Roger Pau Monné ; Ian Jackson
> >
> > Cc: xen-devel@lists.xenproject.org; Wei Liu
> >
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]"):
> On 15.06.2020 15:44, Ian Jackson wrote:
> > Thanks to both for your opinions. I have pushed those two to 4.10 and
> > will
> On 13 Jun 2020, at 01:24, Stefano Stabellini wrote:
>
> On Fri, 12 Jun 2020, Bertrand Marquis wrote:
>>> On 12 Jun 2020, at 02:09, Stefano Stabellini wrote:
>>>
>>> On Thu, 11 Jun 2020, Julien Grall wrote:
Hi Stefano,
On 11/06/2020 19:50, Stefano Stabellini wrote:
> On T
On 15/06/2020 15:07, Ian Jackson wrote:
> Paul Durrant writes ("RE: [PATCH] tools/libxengnttab: correct size of
> allocated memory"):
>>> -Original Message-
>>> From: Xen-devel On Behalf Of
>>> Jürgen Groß
>>> Sent: 11 June 2020 16:26
>>> To: Roger Pau Monné ; Ian Jackson
>>>
>>> Cc: x
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_current() to operate on the full
policy for the cur
This is some work in light of IvyBridge not gaining microcode to combat SRBDS
/ XSA-320. It is a mix of some work I'd planned for 4.15, and some patches
posted already and delayed due to dependence's I'd discovered after-the-fact.
This provides a more user-friendly way of making IvyBridge safe by
In order to combine the functionality of xc_cpuid_set() with
xc_cpuid_apply_policy(), arrange to pass the data in a single contained
struct, rather than two arrays.
libxl__cpuid_policy is the ideal structure to use, but that would introduce a
reverse dependency between libxc and libxl. Introduce
To combat the absence of mitigating microcode, arrange to hide RDRAND by
default on IvyBridge hardware.
Adjust the default feature derivation to hide RDRAND on IvyBridge client
parts, unless `cpuid=rdrand` is explicitly provided.
Adjust the restore path in xc_cpuid_apply_policy() to not hide RDRA
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
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
---
xen/arch/x86/cpuid.c | 2 +
Memory Protection eXtension support has been dropped from GCC and Linux, and
will be dropped from future Intel CPUs.
With all other default/max pieces in place, move MPX from default to max.
This means that VMs won't be offered it by default, but can explicitly opt
into using it via cpuid="host,mp
This reduces the number of CPUID handling entry-points to just one.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Paul Durrant
---
tools/libxc/include/xenctrl.h | 9 -
tools/libxc/xc_cpuid_x86
The toolstack logic can now correctly distinguish a clean boot from a
migrate/restore.
Allow lowercase a/s/h to be used to annotate a non-default feature.
Due to the emulator work prepared earlier in 4.14, this now allows VMs to
explicity opt in to the TSXLDTRK, MOVDIR{I,64B} and SERIALIZE instru
In order to safely disable some features by default, without breaking
migration from 4.13 or older, the CPUID logic needs to distinguish the two
cases.
Plumb a restore boolean down from the two callers of libxl__cpuid_legacy() all
the way down into xc_cpuid_apply_policy().
No functional change.
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 the loop processing down into xc_cpuid_set(), which al
Hi,
puzzle time: In my continuing explorations of the PVHv2 ABIs for the new
MirageOS Xen stack, I've run into some issues with what looks like
missed deliveries of events on event channels.
While a simple unikernel that only uses the Xen console and effectively
does for (1..5) { printf("foo
> Ideally at some point maybe we would make this clearer but not now.
Okay, sounds good.
> Have you tested the situations you describe ? That might be a better
> way of checking that it's right than the code inspection which is
> obviously failing for me now...
Yes, I have tested the following
Nick Rosbrook writes ("Re: [PATCH for-4.14] tools: check go compiler version if
present"):
> > Ideally at some point maybe we would make this clearer but not now.
>
> Okay, sounds good.
>
> > Have you tested the situations you describe ? That might be a better
> > way of checking that it's righ
> -Original Message-
> From: Ian Jackson
> Sent: 15 June 2020 15:42
> To: Nick Rosbrook
> Cc: xen-devel@lists.xenproject.org; p...@xen.org; George Dunlap
> ; Nick
> Rosbrook ; Wei Liu
> Subject: Re: [PATCH for-4.14] tools: check go compiler version if present
>
> Nick Rosbrook writes (
Andrew Cooper writes ("[PATCH for-4.13] tools/libxl: Fix memory leak in
libxl_cpuid_set()"):
> 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_tra
Paul Durrant writes ("RE: [PATCH for-4.14] tools: check go compiler version if
present"):
> > Acked-by: Ian Jackson
> >
> > Paul, this should go into 4.14. Can I have a release ack plase ?
>
> You may...
>
> Release-acked-by: Paul Durrant
Thanks, pushed.
Ian.
Andrew Cooper writes ("[PATCH 1/9] tools/libx[cl]: Introduce struct
xc_xend_cpuid for xc_cpuid_set()"):
> In order to combine the functionality of xc_cpuid_set() with
> xc_cpuid_apply_policy(), arrange to pass the data in a single contained
> struct, rather than two arrays.
>
> libxl__cpuid_polic
Andrew Cooper writes ("[PATCH 2/9] tests/cpu-policy: Confirm that CPUID
serialisation is sorted"):
> 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 s
Andrew Cooper writes ("[PATCH 3/9] tools/libx[cl]: Move processing loop down
into xc_cpuid_set()"):
> 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 re
Andrew Cooper writes ("[PATCH 4/9] tools/libx[cl]: Merge xc_cpuid_set() into
xc_cpuid_apply_policy()"):
> This reduces the number of CPUID handling entry-points to just one.
>
> No functional change.
Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH 5/9] tools/libx[cl]: Plumb bool restore down into
xc_cpuid_apply_policy()"):
> In order to safely disable some features by default, without breaking
> migration from 4.13 or older, the CPUID logic needs to distinguish the two
> cases.
>
> Plumb a restore boolean down
Hi all,
Xen 4.14 RC2 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.14.0-rc2
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.14.0-rc2/xen-4.14.0-rc2.tar.gz
And the signature is at:
https://downloads.xenproject.org/
Andrew Cooper writes ("Re: [PATCH] tools/libxengnttab: correct size of
allocated memory"):
> I already committed it, seeing as it was fully acked.
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=aad20e538d7ba0e36f5ed8d2bebb74096e3a6d7f
That must be why it didn't apply :-).
Thanks,
Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"):
> When iommu is not enabled for a given domain then pci passthrough
> hypercalls such as xc_test_assign_device return EOPNOTSUPP.
> The code responsible for this is in "iommu_do_domctl" inside
> xen/drivers/passthrough/iommu.c
>
On 15/06/2020 15:52, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 2/9] tests/cpu-policy: Confirm that CPUID
> serialisation is sorted"):
>> 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 t
On Mon, Jun 15, 2020 at 04:25:57PM +0200, Martin Lucina wrote:
> Hi,
>
> puzzle time: In my continuing explorations of the PVHv2 ABIs for the new
> MirageOS Xen stack, I've run into some issues with what looks like missed
> deliveries of events on event channels.
That would be weird, as other OSe
On 10.06.2020 16:39, Andrew Cooper wrote:
> On 09/06/2020 14:41, Jan Beulich wrote:
>> On 08.06.2020 22:02, Andrew Cooper wrote:
>>> Do we ever write into .rodata? AFAICT, we introduce new fuctions for
>>> references to new .rodata, rather than modifying existing .rodata. If
>>> however
>>> we d
On 12/06/2020 16:56, Roger Pau Monne wrote:
> Some video BIOS require a PIT in order to work properly, hence classic
> PV dom0 gets partial access to the physical PIT as long as it's not in
> use by Xen.
Is this actually true today?
I can believe that it may have been necessary on old hardware, b
Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID
serialisation is sorted"):
> Nothing runs it by default, but it is part of my prepush testing for
> anything in the relevant area.
>
> We should do something better, but its not totally trivial. The x86
> emulator test f
The xenlight_golang_union_from_C function iterates over a dict to
construct a switch statement that marshals a C keyed union into a Go
type. Because python does not guarantee dict ordering across all
versions, this can result in the switch statement being generated in a
different order depending on
Nick Rosbrook writes ("[PATCH for-4.14] golang/xenlight: sort cases in switch
statement"):
> The xenlight_golang_union_from_C function iterates over a dict to
> construct a switch statement that marshals a C keyed union into a Go
> type. Because python does not guarantee dict ordering across all
>
On Mon, Jun 15, 2020 at 04:33:33PM +0100, Andrew Cooper wrote:
> On 12/06/2020 16:56, Roger Pau Monne wrote:
> > Some video BIOS require a PIT in order to work properly, hence classic
> > PV dom0 gets partial access to the physical PIT as long as it's not in
> > use by Xen.
>
> Is this actually tr
On 2020-06-15 17:03, Roger Pau Monné wrote:
This way of event channel injection is slitgly hackish, and I would
recommend using HVMOP_set_evtchn_upcall_vector, that way vectors will
be properly routed using the lapic.
Using HVM_PARAM_CALLBACK_TYPE_VECTOR vectors are injected without
setting the
On Mon, Jun 15, 2020 at 03:59:50PM +0100, Ian Jackson wrote:
> Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"):
> > When iommu is not enabled for a given domain then pci passthrough
> > hypercalls such as xc_test_assign_device return EOPNOTSUPP.
> > The code responsible for th
> -Original Message-
> From: Ian Jackson
> Sent: 15 June 2020 16:43
> To: Nick Rosbrook
> Cc: xen-devel@lists.xenproject.org; p...@xen.org; Andrew Cooper
> ; Nick
> Rosbrook ; George Dunlap ;
> Wei Liu
> Subject: Re: [PATCH for-4.14] golang/xenlight: sort cases in switch statement
>
>
> On Jun 15, 2020, at 4:43 PM, Ian Jackson wrote:
>
> Nick Rosbrook writes ("[PATCH for-4.14] golang/xenlight: sort cases in switch
> statement"):
>> The xenlight_golang_union_from_C function iterates over a dict to
>> construct a switch statement that marshals a C keyed union into a Go
>> typ
> -Original Message-
> From: Roger Pau Monné
> Sent: 15 June 2020 16:57
> To: Ian Jackson
> Cc: Grzegorz Uriasz ; Jan Beulich ;
> Andrew Cooper
> ; Kevin Tian ; Paul Durrant
> ; Wei Liu
> ; ja...@bartmin.ski; marma...@invisiblethingslab.com;
> j.nowa...@student.uw.edu.pl; Anthony
> Per
On 15/06/2020 16:34, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID
> serialisation is sorted"):
>> Nothing runs it by default, but it is part of my prepush testing for
>> anything in the relevant area.
>>
>> We should do something better, but its
On 11.06.2020 19:11, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 11 June 2020 17:26
>> To: Roger Pau Monne ; xen-devel@lists.xenproject.org
>> Cc: p...@xen.org; Jan Beulich ; Wei Liu
>> Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag fo
Roger Pau Monne writes ("Re: [PATCH] libxl: tooling expects wrong errno"):
> On Mon, Jun 15, 2020 at 03:59:50PM +0100, Ian Jackson wrote:
> > Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"):
> > > When iommu is not enabled for a given domain then pci passthrough
> > > hypercal
On Mon, Jun 15, 2020 at 05:51:51PM +0200, Martin Lucina wrote:
> On 2020-06-15 17:03, Roger Pau Monné wrote:
> > This way of event channel injection is slitgly hackish, and I would
> > recommend using HVMOP_set_evtchn_upcall_vector, that way vectors will
> > be properly routed using the lapic.
> >
On 15/06/2020 15:25, Martin Lucina wrote:
> Hi,
>
> puzzle time: In my continuing explorations of the PVHv2 ABIs for the
> new MirageOS Xen stack, I've run into some issues with what looks like
> missed deliveries of events on event channels.
>
> While a simple unikernel that only uses the Xen cons
> -Original Message-
> From: Xen-devel On Behalf Of Andrew
> Cooper
> Sent: 15 June 2020 15:15
> To: Xen-devel
> Cc: Wei Liu ; Paul Durrant ; Andrew Cooper
> ; Jan
> Beulich ; Ian Jackson ; Roger Pau
> Monné
>
> Subject: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
>
> This is s
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 June 2020 15:29
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu
> Subject: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs
> not requiring an E
> -Original Message-
> From: Jan Beulich
> Sent: 15 June 2020 17:17
> To: p...@xen.org; 'Andrew Cooper'
> Cc: 'Roger Pau Monne' ; xen-devel@lists.xenproject.org;
> 'Wei Liu'
> Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for
> GSIs not requiring an EOI
> or un
> -Original Message-
> From: Ian Jackson
> Sent: 15 June 2020 17:38
> To: Roger Pau Monne
> Cc: Grzegorz Uriasz ; Jan Beulich ;
> Andrew Cooper
> ; Kevin Tian ; Paul Durrant
> ; Wei Liu
> ; ja...@bartmin.ski; marma...@invisiblethingslab.com;
> j.nowa...@student.uw.edu.pl; Anthony
> Per
flight 151118 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151118/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 151073 pass in 151118
test-amd64-i386-xl-qemut-debianh
Paul Durrant writes ("RE: [PATCH] libxl: tooling expects wrong errno"):
> > -Original Message-
> > From: Ian Jackson
> > Thanks for the analysis. So:
> >
> > Acked-by: Ian Jackson
> >
> > This would seem to be a backport candidate. AFAICT check has been
> > there, looking for ENOSYS,
flight 151152 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151152/
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
On Fri, May 29, 2020 at 01:55:08AM +0300, Roman Kagan wrote:
> 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 physica
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 issue with guest EOI
> > > not forwarded to the host. This is on TI Keystone (Cortex A-15).
> >
> > Not that I know of. A-15
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 also the 2nd, as it is suitably ack-ed) was that i
flight 151159 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151159/
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
On Mon, 15 Jun 2020, Bertrand Marquis wrote:
> > On 13 Jun 2020, at 01:24, Stefano Stabellini wrote:
> >
> > On Fri, 12 Jun 2020, Bertrand Marquis wrote:
> >>> On 12 Jun 2020, at 02:09, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Thu, 11 Jun 2020, Julien Grall wrote:
> Hi Stefano,
> >>
On Mon, 15 Jun 2020 at 21:30, Stefano Stabellini wrote:
>
> On Mon, 15 Jun 2020, Bertrand Marquis wrote:
> > > On 13 Jun 2020, at 01:24, Stefano Stabellini
> > > wrote:
> > >
> > > On Fri, 12 Jun 2020, Bertrand Marquis wrote:
> > >>> On 12 Jun 2020, at 02:09, 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 issue with guest EOI
> > > > not forwarded to the host. This is on TI
flight 151128 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151128/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 150176
build-amd64-pr
Hello,
Just to report that I have successfully installed Xen on a Pine
RockPro64 ARM SBC.
I am using Xen 4.13 booting directly from u-boot on an SD card and my
dom0 distribution is Gentoo.
I haven't tried to create a domU yet and I am doing everything via the
serial console so I can't say
On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote:
>
> On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote:
> >
> > I had been working on Xen on the Pi4 by throwing kernels I compiled onto
> > existing sd cards, and this was working fine. I finally got to a full
> > yocto build of the syst
On Mon, 15 Jun 2020, Christopher Clark wrote:
> On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote:
> >
> > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote:
> > >
> > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto
> > > existing sd cards, and this was working
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 the structures would be 32-bit aligned and
Any updates? I am looking forward to this :-)
On Tue, 21 Jan 2020, Bobby Eshleman wrote:
> Hey everybody,
>
> This is an RFC patchset for the very beginnings of adding RISC-V support
> to Xen. This RFC is really just to start a dialogue about supporting
> RISC-V and align with the Xen project a
On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote:
> On Mon, 15 Jun 2020, Christopher Clark wrote:
> > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote:
> > >
> > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard
> > > wrote:
> > > >
> > > > I had been working on Xen on the
On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote:
>
> On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote:
> > On Mon, 15 Jun 2020, Christopher Clark wrote:
> > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote:
> > > >
> > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minya
On Mon, Jun 15, 2020 at 6:03 PM Stefano Stabellini
wrote:
>
> Any updates? I am looking forward to this :-)
At the risk of flooding the list with +1s -- I'm also very much
looking forward to it!
Thanks,
Roman.
>
>
> On Tue, 21 Jan 2020, Bobby Eshleman wrote:
> > Hey everybody,
> >
> > This is a
On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote:
> Any updates? I am looking forward to this :-)
FYI, I would like to talk more about RISC-V Xen at the Xen Virtual
summit. I'll put it forward as a BoF subject.
I haven't worked on this, although the RISC-V Hypervisor spec is
progressin
On Mon, Jun 15, 2020 at 4:35 PM Christopher Clark
wrote:
>
> On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote:
> >
> > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote:
> > >
> > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto
> > > existing sd cards, and thi
Hi Peng,
On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote:
>
> Hi All,
>
> While enabling trusty os with xen, I took same approach as OP-TEE,
> with OP-TEE running in secure world. But I am also thinking this might
> introduce potential issue is that secure world OS communicate with DomU.
> If there
On Mon, Jun 15, 2020 at 06:05:57PM -0700, Roman Shaposhnik wrote:
> On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote:
> >
> > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote:
> > > On Mon, 15 Jun 2020, Christopher Clark wrote:
> > > > On Wed, Jun 10, 2020 at 7:21 PM Roman Sha
On Mon, Jun 15, 2020 at 6:45 PM Corey Minyard wrote:
>
> On Mon, Jun 15, 2020 at 06:05:57PM -0700, Roman Shaposhnik wrote:
> > On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote:
> > >
> > > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote:
> > > > On Mon, 15 Jun 2020, Christop
flight 151139 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151139/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b90beadfae8f1153697fbb87f923cfa14578ee3e
baseline version:
ovmf 9af1064995d479df92e39
Hi,
> Subject: Re: [Tee-dev] TEE with XEN
>
> Hi Peng,
>
> On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote:
> >
> > Hi All,
> >
> > While enabling trusty os with xen, I took same approach as OP-TEE,
> > with OP-TEE running in secure world. But I am also thinking this might
> > introduce potential
flight 151137 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151137/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 150039
test-amd64-amd
flight 151141 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 150120
build-amd64-pre
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 after the RFC).
I've gradually regained free time, and
1 - 100 of 104 matches
Mail list logo
