>>> On 04.09.18 at 18:24, wrote:
> On 04/09/18 17:11, Juergen Gross wrote:
>> On 16/08/18 13:27, Jan Beulich wrote:
>> On 16.08.18 at 12:56, wrote:
On 16/08/18 11:29, Jan Beulich wrote:
> Following some further discussion with Andrew, he looks to be
> convinced that the issue is
>>> On 05.09.18 at 08:56, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, September 5, 2018 2:49 PM
>>
>> >>> On 05.09.18 at 02:42, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Tuesday, September 4, 2018 5:08 PM
>> >>
>> >> >>> On 04.09.18 at
Am Mon, 03 Sep 2018 09:43:45 -0600
schrieb "Jan Beulich" :
> It can easily be expressed through hvm_copy_from_guest_linear(), and in
> two cases this even simplifies callers.
>
> Suggested-by: Paul Durrant
> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
Tested-by: Olaf Hering
Olaf
Am Mon, 03 Sep 2018 09:44:38 -0600
schrieb "Jan Beulich" :
> Assuming consecutive linear addresses map to all RAM or all MMIO is not
> correct. Nor is assuming that a page straddling MMIO access will access
> the same emulating component for both parts of the access. If a guest
> RAM read fails wi
>>> On 04.09.18 at 20:44, wrote:
> On 13/08/18 11:01, Andrew Cooper wrote:
>> This is in preparation to set up d->max_cpus and d->vcpu[] in
>> domain_create(),
>> and allow later parts of domain construction to have access to the values.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beuli
flight 127285 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127285/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 865d7f7b0158f3fb4b3fb187aae4b323a705a8ed
baseline version:
ovmf 04722cfa309104d815257
On 9/5/18 9:56 AM, Jan Beulich wrote:
On 04.09.18 at 22:58, wrote:
>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
In a classic HVI + Xen setup, the introspection engine would monitor
legacy guest page-tables by marking them
On 9/5/18 9:56 AM, Jan Beulich wrote:
On 04.09.18 at 22:58, wrote:
>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
In a classic HVI + Xen setup, the introspection engine would monitor
legacy guest page-tables by marking them
flight 127280 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127280/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127266
test-armhf-armhf-libvirt 14 save
Also CC Linux maintainers.
On Tue, Sep 04, 2018 at 07:27:31PM +0200, Vitaly Kuznetsov wrote:
> Wei Liu writes:
>
> > On Tue, Sep 04, 2018 at 01:39:29PM +0200, Vitaly Kuznetsov wrote:
> >> 'xl sysrq' command doesn't work with modern Linux guests with the following
> >> message in guest's log:
> >
On Tue, Sep 04, 2018 at 01:39:29PM +0200, Vitaly Kuznetsov wrote:
> 'xl sysrq' command doesn't work with modern Linux guests with the following
> message in guest's log:
>
> xen:manage: sysrq_handler: Error -13 writing sysrq in control/sysrq
>
> xenstore trace confirms:
>
> IN 0x24bd9a0 201809
flight 75167 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 75137
Tests which did n
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 September 2018 08:12
> To: Kevin Tian
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Paul Durrant ; Stefano
> Stabellini ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH v6 01/14] iommu
>>> On 05.09.18 at 10:14, wrote:
> On 9/5/18 9:56 AM, Jan Beulich wrote:
> On 04.09.18 at 22:58, wrote:
>>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4533,8
flight 127304 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127304/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebs
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 04 September 2018 21:31
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Jan Beulich
> ; Eslam Elnikety ; Shan Haitao
>
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian
>>> On 05.09.18 at 11:13, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 05 September 2018 08:12
>> To: Kevin Tian
>> Cc: Suravee Suthikulpanit ; Julien Grall
>> ; Paul Durrant ; Stefano
>> Stabellini ; xen-devel > de...@lists.xenproject.org>
>> Sub
On Wed, 2018-09-05 at 09:36 +, Paul Durrant wrote:
>
> I see. Given that Windows has used APIC assist to circumvent its EOI
> then I wonder whether we can get away with essentially doing the
> same. I.e. for a completed APIC assist found in
> vlapic_has_pending_irq() we simply clear the APIC a
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 05 September 2018 10:40
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Jan Beulich
> ; Eslam Elnikety ; Shan Haitao
>
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenb
flight 127302 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127302/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen da3bd8111858a1fb045a6ddc0b36d72164d9c5dd
baseline version:
xen f049
On Wed, Sep 05, 2018 at 09:35:28AM +, osstest service owner wrote:
> flight 127304 freebsd-master real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/127304/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not
On Wed, Sep 05, 2018 at 09:22:03AM +0100, Wei Liu wrote:
> Also CC Linux maintainers.
>
> On Tue, Sep 04, 2018 at 07:27:31PM +0200, Vitaly Kuznetsov wrote:
> > Wei Liu writes:
> >
> > > On Tue, Sep 04, 2018 at 01:39:29PM +0200, Vitaly Kuznetsov wrote:
> > >> 'xl sysrq' command doesn't work with
Wei Liu writes:
> Also CC Linux maintainers.
>
> On Tue, Sep 04, 2018 at 07:27:31PM +0200, Vitaly Kuznetsov wrote:
>> Wei Liu writes:
>>
>> > On Tue, Sep 04, 2018 at 01:39:29PM +0200, Vitaly Kuznetsov wrote:
>> >> 'xl sysrq' command doesn't work with modern Linux guests with the
>> >> followin
On Mon, Sep 03, 2018 at 02:59:42PM +0200, Juergen Gross wrote:
> Trying to set the number of vcpus of a domain to 0 isn't refused.
> We should not allow that.
>
> Signed-off-by: Juergen Gross
> ---
> tools/libxl/libxl_domain.c | 6 ++
> tools/xl/xl_vcpu.c | 5 +++--
> 2 files changed
On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
> Switching to closed state earlier can cause the block-drbd
> script to fail with 'Device is held open by someone':
>
> root: /etc/xen/scripts/block-drbd: remove XENBUS_PATH=backend/vbd/6/51712
> kernel: [ .278235] block drbd6: S
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 05 September 2018 10:43
> To: 'David Woodhouse' ; xen-
> de...@lists.xenproject.org
> Cc: Eslam Elnikety ; Andrew Cooper
> ; Shan Haitao ; Jan
> Beulich
> Subject: Re:
The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
BUG: unable to handle kernel NULL pointer dereference at 02d8
PGD 0 P4D 0
Oops: [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-default #1
openSUSE Tumbleweed (unreleased)
Hardw
On Wed, 2018-09-05 at 10:40 +, Paul Durrant wrote:
>
> Actually the neatest approach would be to get information into the
> vlapic code as to whether APIC assist is suitable for the given
> vector so that the code there can selectively enable it, and then Xen
> would know it was safe to avoid
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: 05 September 2018 11:45
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Eslam Elnikety ; Andrew Cooper
> ; Shan Haitao ; Jan
> Beulich
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian
flight 127289 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
On 05/09/18 12:40, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-
On Wed, Sep 05, 2018 at 11:19:09AM +0100, Wei Liu wrote:
> On Mon, Sep 03, 2018 at 02:59:42PM +0200, Juergen Gross wrote:
> > Trying to set the number of vcpus of a domain to 0 isn't refused.
> > We should not allow that.
> >
> > Signed-off-by: Juergen Gross
> > ---
> > tools/libxl/libxl_domain.
>>> On 05.09.18 at 09:24, wrote:
On 04.09.18 at 20:44, wrote:
>> Unlike the boolean-nature rangeset_contains_*() helpers, I don't think
>> it is reasonable to make rangeset_remove_*() tolerate a NULL rangeset.
>
> +1
Hmm, upon further thought: rangeset_remove_*() is a no-op on an
empty ran
Am Wed, 5 Sep 2018 12:55:58 +0200
schrieb Juergen Gross :
> the last cpu
Which one is the "last" one? I mean, if cpu#0 never can be offlined than
perhaps the code should check for just that and return early. But if cpu#0
could be disabled while some other cpu is the remaining cpu, some other ch
On 05/09/18 13:50, Olaf Hering wrote:
> Am Wed, 5 Sep 2018 12:55:58 +0200
> schrieb Juergen Gross :
>
>> the last cpu
>
> Which one is the "last" one? I mean, if cpu#0 never can be offlined than
> perhaps the code should check for just that and return early. But if cpu#0
> could be disabled whi
On 05/09/18 08:24, Jan Beulich wrote:
On 04.09.18 at 20:44, wrote:
>> On 13/08/18 11:01, Andrew Cooper wrote:
>>> This is in preparation to set up d->max_cpus and d->vcpu[] in
>>> domain_create(),
>>> and allow later parts of domain construction to have access to the values.
>>>
>>> Signed-o
On 05/09/18 12:55, Wei Liu wrote:
> On Wed, Sep 05, 2018 at 11:19:09AM +0100, Wei Liu wrote:
>> On Mon, Sep 03, 2018 at 02:59:42PM +0200, Juergen Gross wrote:
>>> Trying to set the number of vcpus of a domain to 0 isn't refused.
>>> We should not allow that.
>>>
>>> Signed-off-by: Juergen Gross
>>
Hi Julien,
On 04.09.18 22:48, Julien Grall wrote:
On 09/03/2018 06:55 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 03.09.18 20:38, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
>>> On 05.09.18 at 14:04, wrote:
> On 05/09/18 08:24, Jan Beulich wrote:
> On 04.09.18 at 20:44, wrote:
>>> On 13/08/18 11:01, Andrew Cooper wrote:
This is in preparation to set up d->max_cpus and d->vcpu[] in
domain_create(),
and allow later parts of domain construction to ha
Uses MD5 on the host mac address, vm name and vif index to generate the
last three bytes of the vm mac address (for each vm).
It uses the vif index to account for multiple vifs.
MD5 code is originally from the public domain (written by Colin Plumb in
1993), files found in xen/tools/blktap2/driver
Hi,
On 04/09/18 18:25, Amit Singh Tomar wrote:
> This patch adds image size and flags to XEN image header. It uses
> those fields according to the updated Linux kernel image definition.
>
> With this patch bootloader can now place XEN image anywhere in system
> RAM at 2MB aligned address without
On 05/09/18 13:25, Jan Beulich wrote:
On 05.09.18 at 14:04, wrote:
>> On 05/09/18 08:24, Jan Beulich wrote:
>> On 04.09.18 at 20:44, wrote:
On 13/08/18 11:01, Andrew Cooper wrote:
> This is in preparation to set up d->max_cpus and d->vcpu[] in
> domain_create(),
> and a
Hello,
Thanks for having a look.
On Wed, Sep 5, 2018 at 6:07 PM Andre Przywara wrote:
>
> Hi,
>
> I don't think it's helpful to hide that KERNEL_SIZE definition in
> another file. Please just put "_end - start" here.
Yeah, I thought about it and felt that it would be cleaner and more
readable
Hi,
On 05/09/18 13:52, Amit Tomer wrote:
> Hello,
>
> Thanks for having a look.
>
> On Wed, Sep 5, 2018 at 6:07 PM Andre Przywara wrote:
>>
>> Hi,
>>
>> I don't think it's helpful to hide that KERNEL_SIZE definition in
>> another file. Please just put "_end - start" here.
>
> Yeah, I thought
Hi,
On 09/05/2018 01:17 PM, Volodymyr Babchuk wrote:
On 04.09.18 22:48, Julien Grall wrote:
On 09/03/2018 06:55 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 03.09.18 20:38, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Add very basic OP-TEE
Hi Andrew,
On 09/04/2018 08:53 PM, Andrew Cooper wrote:
On 04/09/18 20:35, Julien Grall wrote:
Hi,
On 09/04/2018 08:21 PM, Julien Grall wrote:
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain structure. However this information is
not available
flight 127307 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127307/
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
Hi Volodymyr,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Some fast SMCCC calls to OP-TEE should be handled in a special way.
Capabilities exchange should be filtered out, so only caps
known to mediator are used. Also mediator disables static SHM
memory capability, because it can't share OP
Hi,
On 05.09.18 16:16, Julien Grall wrote:
Hi,
On 09/05/2018 01:17 PM, Volodymyr Babchuk wrote:
On 04.09.18 22:48, Julien Grall wrote:
On 09/03/2018 06:55 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 03.09.18 20:38, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Vol
Hi,
On 09/05/2018 02:38 PM, Volodymyr Babchuk wrote:
Hi,
On 05.09.18 16:16, Julien Grall wrote:
Hi,
On 09/05/2018 01:17 PM, Volodymyr Babchuk wrote:
On 04.09.18 22:48, Julien Grall wrote:
On 09/03/2018 06:55 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 03.09.18 20:38, Jul
I think we have a major problem in our build system regarding
automatic dependencies.
Starting with a new tree (after git clone or make clean) I have
no dependency files (*.d2) anywhere:
$ make clean
$ find . -name '*.d2' | wc -l
0
Doing "make" will produce only some of them in a very limited nu
Signed-off-by: Wei Liu
---
docs/misc/xenstore-paths.markdown | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index 60c8b3fbe5..33d281915c 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-path
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
OP-TEE meditor needs to store per-domain context, as will be seen
s/meditor/mediator/
in the next patches. At this moment it stores only reference to domain.
This allows us to filter out calls from domains that are not allowed
to work wit
elbling boxes uses the mfi driver and have the hard disks in
passthrough mode, which means the mfi driver will expose them as
mfisyspd? instead of mfid?. In order for the installer to detect such
disks add mfisyspd0 to the list of disks to probe.
This should fix the host-install issues reported on
On 05/09/18 16:05, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Wed, Sep 05, 2018 at 03:05:01PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 05/09/18 15:10, Julien Grall wrote:
> Hi,
>
> On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
>> OP-TEE meditor needs to store per-domain context, as will be seen
>
> s/meditor/mediator/
>
>> in the next patches. At this moment it stores only reference to domain.
>>
>> This allows us to filter
Hi,
On 05.09.18 17:10, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
OP-TEE meditor needs to store per-domain context, as will be seen
s/meditor/mediator/
in the next patches. At this moment it stores only reference to domain.
This allows us to filter out calls
Roger Pau Monne writes ("[PATCH] osstest: add missing disk driver name"):
> elbling boxes uses the mfi driver and have the hard disks in
> passthrough mode, which means the mfi driver will expose them as
> mfisyspd? instead of mfid?. In order for the installer to detect such
> disks add mfisyspd0 t
On 09/05/2018 03:23 PM, Volodymyr Babchuk wrote:
Hi,
Hi,
On 05.09.18 17:10, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
OP-TEE meditor needs to store per-domain context, as will be seen
s/meditor/mediator/
in the next patches. At this moment it stores onl
ebitmap.c:244:32: error: invalid conversion specifier 'Z'
[-Werror,-Wformat-invalid-specifier]
"match my size %Zd (high bit was %d)\n", mapunit,
~^
ebitmap.c:245:16: error: format specifies type 'int' but the argument has type
'unsigned long'
[-W
Am Wed, 5 Sep 2018 12:55:58 +0200
schrieb Juergen Gross :
> Instead of trying to fight the symptoms, I think avoiding to offline
> the last cpu would make more sense.
Well, apparently the fix is to leave cpu#0 online because of a backtrace like
that:
WARNING: CPU: 0 PID: 83 at kernel/sched/cpud
On 05/09/18 16:47, Olaf Hering wrote:
> Am Wed, 5 Sep 2018 12:55:58 +0200
> schrieb Juergen Gross :
>
>> Instead of trying to fight the symptoms, I think avoiding to offline
>> the last cpu would make more sense.
>
> Well, apparently the fix is to leave cpu#0 online because of a backtrace like
>
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue standard SMCCC
NIT: The main way
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contranst with
Am Wed, 5 Sep 2018 17:14:48 +0200
schrieb Juergen Gross :
> I'm not sure this WARN triggers because it is cpu#0. Are you sure
> the tested cpu in that WARN was 0? After all the test is just running
> on cpu#0 and I don't think it can be offline already.
If I leave cpu#0 alone, no WARN is triggere
On Wed, Sep 05, 2018 at 01:39:18PM +0100, Andrew Cooper wrote:
> On 05/09/18 13:25, Jan Beulich wrote:
> On 05.09.18 at 14:04, wrote:
> >> On 05/09/18 08:24, Jan Beulich wrote:
> >> On 04.09.18 at 20:44, wrote:
> The path which blows up is:
>
> arch_domain_destroy()
>
flight 127312 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127312/
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
On Wed, Sep 05, 2018 at 12:36:49PM +0200, Roger Pau Monné wrote:
> On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
> > Switching to closed state earlier can cause the block-drbd
> > script to fail with 'Device is held open by someone':
> >
> > root: /etc/xen/scripts/block-drbd: rem
On Wed, Sep 05, 2018 at 01:35:15PM +0200, Valentin Vidic wrote:
> > AFAICT, this will cause the backend to never switch to 'Closed' state
> > until the toolstack sets online to 0, which is not good IMO.
> >
> > If for example a frontend decides to close a device, the backend will
> > stay in state
On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
wrote:
>
> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
> > On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
> >>
> >> In a classic HVI + Xen setup, the introspection engine would monitor
> >> legacy guest page-tables by marking them read-only inside
On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
> On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
> wrote:
>>
>> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
>>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
In a classic HVI + Xen setup, the introspection engine would monitor
legacy gue
flight 127284 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127284/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 125898
flight 127296 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127296/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 6 xen-install fail REGR. vs. 127001
Tests which did not succeed,
ARM currently has no restrictions on toolstack and guest access to the entire
HVM_PARAM block. As the paging/monitor/sharing features aren't under security
support, this doesn't need an XSA.
The CALLBACK_IRQ and {STORE,CONSOLE}_{PFN,EVTCHN} details exposed read-only to
the guest, while the *_RING
These values are set by the toolstack for each create/restore operation, and
bound by xen{store,console}d before the the guest starts running.
A guest has no reason to modify them at all, and the matching *_PFN parameters
are already read-only. Adjust the *_EVTCHN permissions to be consistent.
S
The parameter marshalling and xsm checks are common to both the set and get
paths. Lift all of the common code out into do_hvm_op() and let
hvmop_{get,set}_param() operate on struct xen_hvm_param directly.
This is somewhat noisy in the functions as each a. reference has to change to
a-> instead.
flight 127299 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127299/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8a204b2aca5a137651ba0665d4ea012d6241fb15
baseline version:
ovmf 865d7f7b0158f3fb4b3fb
There are holes in the HVM_PARAM space, some of which are from deprecated
parameters, but toolstack and device models currently have blanket read
access.
Rearrange hvm_allow_get_param() to have a whitelist of toolstack-readable
parameters, with the default case failing with -EINVAL (which subsumes
There are holes in the HVM_PARAM space, some of which are from deprecated
parameters, but toolstack and device models currently has (almost) blanket
write access.
Rearrange hvm_allow_get_param() to have a whitelist of toolstack-writeable
parameters, with the default case failing with -EINVAL. Thi
This started with the observation in patch 5, and expanded from there. The
end result should be rather more predictable and easy to deprecate parameters
from.
An observation which I haven't addressed (and don't have time in the near
future) is that the hvm params array is moderately wasteful on x
On Wed, Sep 5, 2018 at 10:40 AM Razvan Cojocaru
wrote:
>
> On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
> > On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
> > wrote:
> >>
> >> On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
> >>> On Mon, Sep 3, 2018 at 10:59 PM Adrian Pop wrote:
>
> In a class
On 05/09/18 19:40, Tamas K Lengyel wrote:
> On Wed, Sep 5, 2018 at 10:40 AM Razvan Cojocaru
> wrote:
>> On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
>>> On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
>>> wrote:
On 9/4/18 11:40 PM, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 10:59 PM Adr
On 9/5/18 9:40 PM, Tamas K Lengyel wrote:
>>> Sounds good, thanks!
>> May we take that as an Acked-by, or are there are other things you think
>> we should address?
> A Reviewed-by would be appropriate, I don't think the files touched in
> this patch fall under our umbrella.
You're right, I just s
Since its introduction in c/s 8cbb5278e "x86/AMD: Add support for AMD's OSVW
feature in guests", the OSVW data has been corrected to be per-domain rather
than per-vcpu, and is initialised during XEN_DOMCTL_createdomain.
Furthermore, because XENPF_microcode_update uses hypercall continuations to
mo
flight 127297 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127297/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12 guest-
Patch 5 fixes a long standing problem found by some very slow hosts in
xen's osstest
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01945.html
While working on the fix, I discovered other problems in libxl's V3
migration protocol. E.g. a modify job on the migrating VM was not
han
The libxlDomainMigrationSrc* functions are a bit flawed in their
handling of modify jobs. A job begins at the start of the begin
phase but ends before the phase completes. No job is running for
the remaining phases of migration on the source host.
Change the logic to keep the job running after a s
libxlDoMigrateSrcP2P() performs all phases of the migration
protocol for peer-to-peer migration. Unfortunately the logic
was a bit flawed since it is possible to skip the confirm
phase after a successfull begin and prepare phase. Fix the
logic to always call the confirm phase after a successful beg
It is possible the incoming VM is not fully started when the finish
phase of migration is executed. In libxlDomainMigrationDstFinish,
wait for the thread receiving the VM to complete before executing
finish phase tasks.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_domain.h| 1 +
src/libxl/
If for any reason the restore of a VM fails on the destination host
in a migration operation, the VM is removed (if not persistent) from
the virDomainObjList, meaning it is no longer available for additional
cleanup or processing in the finish phase. Defer removing the VM from
the virDomainObjList
The libxlDomainMigrationDst* functions are a bit flawed in their
handling of modify jobs. A job begins when the destination host
begins receiving the incoming VM and ends after the VM is started.
The finish phase contains another BeginJob/EndJob sequence.
This patch changes the logic to begin a jo
On 08/24/2018 02:58 AM, Wei Liu wrote:
On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote:
On 08/21/2018 05:14 AM, Jan Beulich wrote:
On 21.08.18 at 03:11, wrote:
flight 126201 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126201/
Regressions :-(
Tests
Since libvirt commit 60d9ad6f GnuTLS is required to build libvirt. The
various libvirt build tests in osstest began failing after the commit
hit libvirt.git master. Adding libgnutls28-dev to the list of packages
needed to build libvirt will fix the currently broken builds.
Signed-off-by: Jim Fehli
flight 127298 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127298/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl 4 host-install
On Wed, Sep 5, 2018 at 12:45 PM Andrew Cooper wrote:
>
> On 05/09/18 19:40, Tamas K Lengyel wrote:
> > On Wed, Sep 5, 2018 at 10:40 AM Razvan Cojocaru
> > wrote:
> >> On 9/5/18 7:28 PM, Tamas K Lengyel wrote:
> >>> On Tue, Sep 4, 2018 at 2:58 PM Razvan Cojocaru
> >>> wrote:
> On 9/4/18 11:4
flight 127301 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127301/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 127280
Tests which did no
Hi,
I hit an issue on xen dom0 when working with most recent mainline linux. I am
posting this to share the symptom and commit fixing the issue, so that people
would be able to search via google in the future when hit the same issue.
The issue is already fixed by Michal Hocko and the patch set
i
device_unregister will put device, do not need to do it one more time
Signed-off-by: Ding Xiang
---
drivers/xen/xenbus/xenbus_probe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 5b47188..cfaa878 100644
--- a/driv
The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
BUG: unable to handle kernel NULL pointer dereference at 02d8
PGD 0 P4D 0
Oops: [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-default #1
openSUSE Tumbleweed (unreleased)
Hardw
100 matches
Mail list logo
