>>> On 04.02.19 at 20:44, wrote:
> On 04/02/2019 09:16, Jan Beulich wrote:
> On 01.02.19 at 18:09, wrote:
>>> A subsequent #DB getting raised causes #GP to turn into #DF.
>> The table on the #DF page clearly says
>> otherwise, at least according to my reading.
>
> Hmm - so it does. Looks li
Benign exceptions, no matter whether they're first or second, will never
cause #DF (a benign exception being second can basically only be #AC, as
in the XSA-156 scenario).
Sadly neither AMD nor Intel really define what happens with two benign
exceptions - the term "sequentially" used by both is po
On 05/02/2019 06:55, Peng Fan wrote:
> On i.MX8, we implemented partition reboot which means Cortex-A reboot
> will not impact M4 cores and System control Unit core. However GICv3
> is not reset because we also need to support A72 Cluster reboot without
> affecting A53 Cluster.
>
> The gic-v3 cont
flight 132911 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132911/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat
fail REGR. vs. 132599
Tests wh
flight 132908 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132908/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132395
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
flight 132889 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132889/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail blocked in
130954
test-amd64-i386-xl-qemuu-
flight 132947 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132947/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 132854 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-xl-
Interrupts could be ACTIVE at boot. Make sure to deactivate them during
initialization.
Signed-off-by: Stefano Stabellini
CC: julien.gr...@arm.com
CC: peng@nxp.com
CC: jgr...@suse.com
---
xen/arch/arm/gic-v2.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/gic-v2.c b/xe
On Sat, 2 Feb 2019, Julien Grall wrote:
> This chunk looks good. I will also write a patch for GICv2 doing the same.
No worries, Julien. I'll send the patch.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
On Tue, 5 Feb 2019, Julien Grall wrote:
> Sorry for the formatting.
>
> On Tue, 5 Feb 2019, 20:04 Stefano Stabellini, wrote:
> On Tue, 5 Feb 2019, Jan Beulich wrote:
> > >>> On 05.02.19 at 01:39, wrote:
> > > On Wed, 30 Jan 2019, Christopher Clark wrote:
> > >> +#include
Sorry for the formatting.
On Tue, 5 Feb 2019, 20:04 Stefano Stabellini,
wrote:
> On Tue, 5 Feb 2019, Jan Beulich wrote:
> > >>> On 05.02.19 at 01:39, wrote:
> > > On Wed, 30 Jan 2019, Christopher Clark wrote:
> > >> +#include
> > >> +#include
> > >> +
> > >> +long
> > >> +do_argo_op(unsigned
On Tue, 5 Feb 2019, Peng Fan wrote:
> On i.MX8, we implemented partition reboot which means Cortex-A reboot
> will not impact M4 cores and System control Unit core. However GICv3
> is not reset because we also need to support A72 Cluster reboot without
> affecting A53 Cluster.
>
> The gic-v3 contr
On Tue, 5 Feb 2019, Andrii Anisov wrote:
> On 05.02.19 00:06, Julien Grall wrote:
> > > A57+A53.
> > >
> > > I see the following in my log:
> > >
> > > (XEN) alternatives: Patching with alt table 002c6608 ->
> > > 002c6c80
> > > (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAR
On Tue, 5 Feb 2019, Andrii Anisov wrote:
> Hello Stefano,
>
> On 05.02.19 03:02, Stefano Stabellini wrote:
> > Please send an update soon as I would like to get it in 4.12.
>
> It is already there [1] [2].
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02048.html
> [2]
>
On Tue, 5 Feb 2019, Jan Beulich wrote:
> >>> On 05.02.19 at 01:39, wrote:
> > On Wed, 30 Jan 2019, Christopher Clark wrote:
> >> +#include
> >> +#include
> >> +
> >> +long
> >> +do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
> >> + XEN_GUEST_HANDLE_PARAM(void) arg2, un
flight 132831 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 12 guest-start fail REGR. vs. 132754
test-arm64-arm64-xl
On 2/5/19 9:33 AM, Jan Beulich wrote:
On 05.02.19 at 09:29, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1794,7 +1794,7 @@ static void svm_do_nested_pgfault(struct vcpu *v,
>> uint64_t gpa;
>> uint64_t mfn;
>> uin
>>> On 05.02.19 at 16:53, wrote:
> On Tue, Feb 05, 2019 at 08:15:27AM -0700, Jan Beulich wrote:
>> >>> On 05.02.19 at 14:52, wrote:
>> > I don't think the amount of guest memory matters here, the following
>> > example with 8G of RAM and 8 vCPUs fails in the same way:
>> >
>> > # cat test.c
>> >
On 2/5/19 10:09 AM, Norbert Manthey wrote:
> A pointer mismatch has been reported when compiling with the
> compiler goto-gcc of the bounded model checker CBMC.
> To keep trace entry size independent of the compiler implementation,
> use the available p2mt variable for the access, and update the
>
On 2/5/19 4:33 AM, Jan Beulich wrote:
>
> SVM maintainers / George: I find it odd that there are two calls
> to __get_gfn_type_access() here. Doesn't this bear the risk of
> the trace record not reflecting what has actually happened (i.e.
> what has lead to the domain crash)? Perhaps the better fix
flight 132847 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132847/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131842
test-armhf-armhf-libvirt 14 sav
On Tue, Feb 05, 2019 at 08:15:27AM -0700, Jan Beulich wrote:
> >>> On 05.02.19 at 14:52, wrote:
> > On Tue, Feb 05, 2019 at 05:55:50AM -0700, Jan Beulich wrote:
> >> >>> On 05.02.19 at 12:47, wrote:
> >> > On Tue, Feb 05, 2019 at 04:21:52AM -0700, Jan Beulich wrote:
> >> >> >>> On 30.01.19 at 11:
>>> On 04.02.19 at 20:44, wrote:
> On 04/02/2019 09:16, Jan Beulich wrote:
> On 01.02.19 at 18:09, wrote:
>>> On 01/02/2019 16:55, Jan Beulich wrote:
>>> On 01.02.19 at 17:25, wrote:
> If it were just getting insn_len incorrectly as 0, then the guest would
> livelock as we wouldn
On Tue, Feb 05, 2019 at 08:18:52AM -0700, Jan Beulich wrote:
> >>> On 05.02.19 at 15:01, wrote:
> > On Tue, Feb 05, 2019 at 05:49:07AM -0700, Jan Beulich wrote:
> >> >>> On 05.02.19 at 12:15, wrote:
> >> > On Tue, Feb 05, 2019 at 03:47:49AM -0700, Jan Beulich wrote:
> >> >> >>> On 30.01.19 at 11:
>>> On 05.02.19 at 15:01, wrote:
> On Tue, Feb 05, 2019 at 05:49:07AM -0700, Jan Beulich wrote:
>> >>> On 05.02.19 at 12:15, wrote:
>> > On Tue, Feb 05, 2019 at 03:47:49AM -0700, Jan Beulich wrote:
>> >> >>> On 30.01.19 at 11:36, wrote:
>> >> > --- a/xen/drivers/passthrough/x86/iommu.c
>> >> > +
>>> On 05.02.19 at 14:52, wrote:
> On Tue, Feb 05, 2019 at 05:55:50AM -0700, Jan Beulich wrote:
>> >>> On 05.02.19 at 12:47, wrote:
>> > On Tue, Feb 05, 2019 at 04:21:52AM -0700, Jan Beulich wrote:
>> >> >>> On 30.01.19 at 11:36, wrote:
>> >> > Current code in shadow_enable will allocate a shado
A pointer mismatch has been reported when compiling with the
compiler goto-gcc of the bounded model checker CBMC.
To keep trace entry size independent of the compiler implementation,
use the available p2mt variable for the access, and update the
trace record independenly.
Fixes: 9a779e4f (Implemen
On Mon, Feb 4, 2019 at 9:37 AM Jan Beulich wrote:
>
> >>> On 01.02.19 at 19:52, wrote:
>
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In particu
flight 132846 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132846/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 132776
Tests which did not suc
>>> On 05.02.19 at 14:38, wrote:
> On Tue, Feb 05, 2019 at 05:44:14AM -0700, Jan Beulich wrote:
>> >>> On 05.02.19 at 11:40, wrote:
>> > On Tue, Feb 05, 2019 at 12:45:56AM -0700, Jan Beulich wrote:
>> >> >>> On 04.02.19 at 18:18, wrote:
>> >> > On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beuli
>>> On 05.02.19 at 15:23, wrote:
> On 1/31/19 17:35, Jan Beulich wrote:
> On 29.01.19 at 15:43, wrote:
>>> @@ -1942,6 +1942,12 @@ Irrespective of Xen's setting, the feature is
> virtualised for HVM guests to
>>> use. By default, Xen will enable this mitigation on hardware believed to
>>>
On 1/31/19 18:05, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
>> L1 cache is problemetic, because when hyperthreading is used as well, a
>> guest running on the sibling core can leak this potentially secret data.
On 1/31/19 17:35, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> @@ -1942,6 +1942,12 @@ Irrespective of Xen's setting, the feature is
>> virtualised for HVM guests to
>> use. By default, Xen will enable this mitigation on hardware believed to
>> be
>> vulnerable to L1TF.
>>
>> +On
flight 132857 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132857/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3b6c73f13eac3dc8bf7deb95237cd3f6abf40ce3
baseline version:
ovmf 6c61ec4c62b6d1001e8ea
On Tue, Feb 05, 2019 at 05:49:07AM -0700, Jan Beulich wrote:
> >>> On 05.02.19 at 12:15, wrote:
> > On Tue, Feb 05, 2019 at 03:47:49AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.19 at 11:36, wrote:
> >> > Reserved memory ranges below 1MB on a PVH dom0 are added to the HAP
> >> > page tables, but
On Tue, Feb 05, 2019 at 05:55:50AM -0700, Jan Beulich wrote:
> >>> On 05.02.19 at 12:47, wrote:
> > On Tue, Feb 05, 2019 at 04:21:52AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.19 at 11:36, wrote:
> >> > Current code in shadow_enable will allocate a shadow pool of 4MB
> >> > regardless of the v
On 2/1/19 15:08, Jan Beulich wrote:
On 01.02.19 at 14:45, wrote:
>> On 1/31/19 16:05, Jan Beulich wrote:
>> On 29.01.19 at 15:43, wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
On Tue, Feb 05, 2019 at 05:44:14AM -0700, Jan Beulich wrote:
> >>> On 05.02.19 at 11:40, wrote:
> > On Tue, Feb 05, 2019 at 12:45:56AM -0700, Jan Beulich wrote:
> >> >>> On 04.02.19 at 18:18, wrote:
> >> > On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
> >> >> >>> On 30.01.19 at 11:
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-i386
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xe
On 2/5/19 3:02 PM, Hans Verkuil wrote:
On 2/5/19 1:30 PM, Oleksandr Andrushchenko wrote:
Sorry for paying so much attention to this, but I think it is important that
this is documented precisely.
Thank you for helping with this - your comments are really
important and make the description preci
On 2/5/19 1:30 PM, Oleksandr Andrushchenko wrote:
>> Sorry for paying so much attention to this, but I think it is important that
>> this is documented precisely.
> Thank you for helping with this - your comments are really
> important and make the description precise. Ok, so finally:
>
> * num_b
>>> On 05.02.19 at 12:47, wrote:
> On Tue, Feb 05, 2019 at 04:21:52AM -0700, Jan Beulich wrote:
>> >>> On 30.01.19 at 11:36, wrote:
>> > Current code in shadow_enable will allocate a shadow pool of 4MB
>> > regardless of the values of sh_min_allocation or
>> > shadow_min_acceptable_pages, which m
>>> On 05.02.19 at 12:15, wrote:
> On Tue, Feb 05, 2019 at 03:47:49AM -0700, Jan Beulich wrote:
>> >>> On 30.01.19 at 11:36, wrote:
>> > Reserved memory ranges below 1MB on a PVH dom0 are added to the HAP
>> > page tables, but due to this being done before setting up the IOMMU
>> > the non RAM re
>>> On 05.02.19 at 11:40, wrote:
> On Tue, Feb 05, 2019 at 12:45:56AM -0700, Jan Beulich wrote:
>> >>> On 04.02.19 at 18:18, wrote:
>> > On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
>> >> >>> On 30.01.19 at 11:36, wrote:
>> >> > The assert was originally added to make sure that h
On 2/5/19 2:14 PM, Hans Verkuil wrote:
On 2/5/19 12:44 PM, Oleksandr Andrushchenko wrote:
On 2/5/19 12:53 PM, Hans Verkuil wrote:
On 2/5/19 11:44 AM, Oleksandr Andrushchenko wrote:
On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
On 1/23/19 10:14 AM,
On 2/5/19 12:44 PM, Oleksandr Andrushchenko wrote:
> On 2/5/19 12:53 PM, Hans Verkuil wrote:
>> On 2/5/19 11:44 AM, Oleksandr Andrushchenko wrote:
>>> On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
> On 1/23/19 10:14 AM, Oleksandr Andrushchenko wr
Ian Jackson writes ("Re: [PATCH for-4.12] libxl: correctly dispose of dominfo
list in libxl_name_to_domid"):
> Wei Liu writes ("[PATCH for-4.12] libxl: correctly dispose of dominfo list in
> libxl_name_to_domid"):
> > Tamas reported ssid_label was leaked. Use the designated function to
> > free d
On Tue, Feb 05, 2019 at 04:21:52AM -0700, Jan Beulich wrote:
> >>> On 30.01.19 at 11:36, wrote:
> > Current code in shadow_enable will allocate a shadow pool of 4MB
> > regardless of the values of sh_min_allocation or
> > shadow_min_acceptable_pages, which means that calls to
> > shadow_alloc_p2m_
On 2/5/19 12:53 PM, Hans Verkuil wrote:
On 2/5/19 11:44 AM, Oleksandr Andrushchenko wrote:
On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
While I am still l
Wei Liu writes ("Re: [PATCH-for-4.10/4.11] libxl: don't set gnttab limits in
soft reset case"):
> On Thu, Jan 17, 2019 at 05:40:59PM +0100, Juergen Gross wrote:
> > In case of soft reset the gnttab limit setting will fail, so omit it.
> > Setting of max vcpu count is pointless in this case, too, s
Jan Beulich writes ("Re: [Xen-devel] preparations for 4.10.3 and 4.9.4"):
> On 01.02.19 at 12:23, wrote:
> > For 4.10.3:
> >
> > https://lists.xen.org/archives/html/xen-devel/2019-01/msg01451.html
>
> Ian, this looks to be one for you.
Indeed, thanks.
Ian.
___
>>> On 05.02.19 at 11:26, wrote:
> Would you be fine with the following message:
>
> "
> The p2m and iommu mapping code always had the requirement that
> addresses and orders must be aligned when populating the p2m or the
> iommu page tables.
>
> PVH dom0 builder didn't take this requirement int
>>> On 05.02.19 at 11:54, wrote:
> On 05/02/2019 07:42, Jan Beulich wrote:
> On 04.02.19 at 18:11, wrote:
>>> On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
>>> On 30.01.19 at 11:36, wrote:
> Due to the recent changes in the iommu mapping logic, the start
> addresse
>>> On 30.01.19 at 11:36, wrote:
> Current code in shadow_enable will allocate a shadow pool of 4MB
> regardless of the values of sh_min_allocation or
> shadow_min_acceptable_pages, which means that calls to
> shadow_alloc_p2m_page can fail even after the check and allocation
> done just above.
>
On Tue, Feb 05, 2019 at 03:47:49AM -0700, Jan Beulich wrote:
> >>> On 30.01.19 at 11:36, wrote:
> > Reserved memory ranges below 1MB on a PVH dom0 are added to the HAP
> > page tables, but due to this being done before setting up the IOMMU
> > the non RAM regions in those areas are not added to th
On 2/5/19 11:44 AM, Oleksandr Andrushchenko wrote:
> On 2/5/19 11:34 AM, Hans Verkuil wrote:
>> On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
>>> On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
>>> While I am still looking forward to any co
On 05/02/2019 07:42, Jan Beulich wrote:
On 04.02.19 at 18:11, wrote:
>> On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
>> On 30.01.19 at 11:36, wrote:
Due to the recent changes in the iommu mapping logic, the start
addresses provided need to be aligned to the orde
>>> On 30.01.19 at 11:36, wrote:
> Reserved memory ranges below 1MB on a PVH dom0 are added to the HAP
> page tables, but due to this being done before setting up the IOMMU
> the non RAM regions in those areas are not added to the IOMMU page
> tables. Fix this by making sure any reserved regions b
On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
While I am still looking forward to any comments from Xen community...
On 1/15/19 4:44 PM, Hans Verkuil wrote:
On Tue, Feb 05, 2019 at 12:45:56AM -0700, Jan Beulich wrote:
> >>> On 04.02.19 at 18:18, wrote:
> > On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.19 at 11:36, wrote:
> >> > The assert was originally added to make sure that higher order
> >> > regions (> PAGE_ORDER
On Mon, Feb 04, 2019 at 12:56:13PM -0800, Christopher Clark wrote:
>
> Wei,
>
> do you have any feedback on the latest argo MAINTAINERS patch?
It looks fine to me.
Wei.
>
> Christopher
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
On Tue, Feb 05, 2019 at 12:42:02AM -0700, Jan Beulich wrote:
> >>> On 04.02.19 at 18:11, wrote:
> > On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.19 at 11:36, wrote:
> >> > Due to the recent changes in the iommu mapping logic, the start
> >> > addresses provided n
On Tue, Feb 05, 2019 at 11:54:12AM +0200, Andrii Anisov wrote:
> Hello Roger,
>
> On 05.02.19 11:45, Roger Pau Monné wrote:
> > You should see a reasonable amount of stolen time. A simple test would
> > be to spin 2 VMs with 1 vCPU each and pin them to the same physical
> > CPU. Then run a CPU int
Hello Roger,
On 05.02.19 11:45, Roger Pau Monné wrote:
You should see a reasonable amount of stolen time. A simple test would
be to spin 2 VMs with 1 vCPU each and pin them to the same physical
CPU. Then run a CPU intensive workload on each of them, and the 'st'
time shown in `top` should be ~50
On Tue, Feb 05, 2019 at 10:40:19AM +0200, Andrii Anisov wrote:
>
>
> On 04.02.19 23:58, Julien Grall wrote:
> > Thank you for writing a patch. I am back in France this week for family
> > reason and will not have time properly give a spin this week. Stefano,
> > Andrii, can you test it?
> I'll
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
> On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
>> Any comments from Xen community?
>> Konrad?
> While I am still looking forward to any comments from Xen community...
>>
>> On 1/15/19 4:44 PM, Hans Verkuil wrote:
>>> Hi Oleksandr,
>>>
>>> Jus
>>> On 05.02.19 at 09:29, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1794,7 +1794,7 @@ static void svm_do_nested_pgfault(struct vcpu *v,
> uint64_t gpa;
> uint64_t mfn;
> uint32_t qualification;
> -uint32_t
On 05/02/2019 08:29, Norbert Manthey wrote:
> A pointer mismatch has been reported when compiling with the
> compiler goto-gcc of the bounded model checker CBMC.
>
> Fixes: 9a779e4f (Implement SVM specific part for Nested Virtualization)
>
> Signed-off-by: Norbert Manthey
>
> ---
> xen/arch/x86/h
On Mon, Feb 04, 2019 at 09:58:43PM +, Julien Grall wrote:
> Hi,
>
> On 2/4/19 12:53 PM, Roger Pau Monné wrote:
> > On Fri, Feb 01, 2019 at 05:40:14PM +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 01/02/2019 16:53, Roger Pau Monné wrote:
> > Thanks!
> >
> > Here is an updated version wh
On 05.02.19 03:10, Stefano Stabellini wrote:
You really want to fix this in the Linux driver if you can, because
you'll get better performance and a more stable system.
I also have an idea that it might improve performance. And it is what we need.
In the short
term, I would suggest you keep
flight 132832 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132832/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd f2704b103eb396f8e9139b73406b504b837dfb61
baseline version:
freebsd 711fa71dfed
On 05.02.19 00:06, Julien Grall wrote:
A57+A53.
I see the following in my log:
(XEN) alternatives: Patching with alt table 002c6608 ->
002c6c80
(XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 o
flight 132820 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132820/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132759
test-amd64-amd64-xl-qemuu-win7-amd64
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
While I am still looking forward to any comments from Xen community...
On 1/15/19 4:44 PM, Hans Verkuil wrote:
Hi Oleksandr,
Just two remaining comments:
On 1/15/19 10:38 AM, Oleksandr Andrushchenko
On 04.02.19 23:58, Julien Grall wrote:
Thank you for writing a patch. I am back in France this week for family reason
and will not have time properly give a spin this week. Stefano, Andrii, can you
test it?
I'll do that today.
Guys, could you please suggest what are evidences that runstate f
Hello Stefano,
On 05.02.19 03:02, Stefano Stabellini wrote:
Please send an update soon as I would like to get it in 4.12.
It is already there [1] [2].
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg02048.html
[2]
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=86354
A pointer mismatch has been reported when compiling with the
compiler goto-gcc of the bounded model checker CBMC.
Fixes: 9a779e4f (Implement SVM specific part for Nested Virtualization)
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/svm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
>>> On 05.02.19 at 01:39, wrote:
> On Wed, 30 Jan 2019, Christopher Clark wrote:
>> +#include
>> +#include
>> +
>> +long
>> +do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
>> + XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
>> + unsigned long arg4)
>>
79 matches
Mail list logo
