> On 18. Sep 2019, at 17:23, Lars Kurth wrote:
>
>
>
> On 18/09/2019, 12:27, "Wieczorkiewicz, Pawel" wrote:
>
>
>
>> On 18. Sep 2019, at 13:19, Julien Grall wrote:
>>
>> Hi Pawel,
>>
>> On 18/09/2019 11:44, Wieczorkiewicz, Pawel wrote:
On 18. Sep 2019, at 12:41, Ian Jackson wrot
flight 141454 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141430 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141430/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 141376
test-amd64-i386-xl-qemuu-win7-amd64
flight 141419 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141419/
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. 141354
Tests which did not
flight 141450 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141450/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
flight 141420 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141420/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 2fa3479cfadb0bb3fe694dbfd29f2350eb2570df
baseline version:
freebsd a3dbacfc31a
flight 141407 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
flight 141415 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141415/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141384
test-armhf-armhf-libvirt-raw 13 saveresto
flight 141394 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which did not s
flight 141386 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141386/
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. 133580
test-amd64-i386-exa
flight 141440 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job test-armhf-armhf-xl
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.g
On 9/16/19 11:48 PM, Jan Beulich wrote:
> On 17.09.2019 00:20, Joe Jin wrote:
>> On 9/16/19 1:01 AM, Jan Beulich wrote:
>>> On 13.09.2019 18:38, Joe Jin wrote:
On 9/13/19 12:14 AM, Jan Beulich wrote:
> On 12.09.2019 20:03, Joe Jin wrote:
>> --- a/xen/drivers/passthrough/io.c
>> +++
flight 141410 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141410/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 82c1a2120855e7fe32417870910f4ce20dca97a3
baseline version:
ovmf 18be724e302295164f00c
flight 141392 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141392/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 141254
Tests which did not s
flight 141400 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141400/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139910
Tests which are fail
On 18/09/2019 07:34, Jan Beulich wrote:
> On 17.09.2019 19:17, Andrew Cooper wrote:
>> On 16/09/2019 10:48, Jan Beulich wrote:
>>> XED commit 1b2fd94425 ("Update MOVSXD to modern behavior") points out
>>> that as of SDM rev 064 MOVSXD is specified to read only 16 bits from
>>> memory (or register)
Hello,
This is the second version for maturing the OP-TEE mediator.
Changes also can be pulled from [2].
Changes from v1:
- Added patch that updates SUPPORT.md
- Instead of removing "experimental" status I changed it to "Tech Preview"
- Other changes are described in the corresponding patches
OP-TEE mediator now is "Tech Preview" state, and we want to update
it's description in Kconfig accordingly.
Signed-off-by: Volodymyr Babchuk
---
Note to commiter: this patch depends on first 4 patches in the series.
---
xen/arch/arm/tee/Kconfig | 12
1 file changed, 8 insertions(+
We want to limit number of calls to lookup_and_pin_guest_ram_addr()
per one request. There are two ways to do this: either preempt
translate_noncontig() or limit size of one shared buffer size.
It is quite hard to preempt translate_noncontig(), because it is deep
nested. So we chose the second opt
We can check for hypercall_preempt_check() in the loop inside
optee_relinquish_resources() to increase hypervisor responsiveness in
case if preemption is required.
Signed-off-by: Volodymyr Babchuk
---
Changes from v1:
- Removed extra hypercall_preempt_check()
- Updated the commit message
---
There is a case possible, when OP-TEE asks guest to allocate shared
buffer, but Xen for some reason can't translate buffer's addresses. In
this situation we should do two things:
1. Tell guest to free allocated buffer, so there will be no memory
leak for guest.
2. Tell OP-TEE that buffer allocati
With the latest patches to the mediator, it can be considered
as Technological Preview feature.
Signed-off-by: Volodymyr Babchuk
---
Note for commiter:
Obviously this patch should be merged after all other patches in
this series.
---
SUPPORT.md | 4
1 file changed, 4 insertions(+)
diff -
We want to limit number of shared buffers that guest can register in
OP-TEE. Every such buffer consumes XEN resources and we don't want
guest to exhaust XEN. So we choose arbitrary limit for shared buffers.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 30 ++
flight 141433 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141433/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On Wed, Sep 18, 2019 at 05:14:06PM +0100, Ian Jackson wrote:
> ./configure takes a PYTHON=... argument. You can use this to specify
> the python interpreter. However, for no good reason, it expects an
> absolute path.
>
> Fix this. The new logic is:
> * if not set, default to `python'
> * if
On Wed, Sep 18, 2019 at 03:23:45PM +0100, Anthony PERARD wrote:
> On Tue, Sep 17, 2019 at 06:19:14PM +0100, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH 28/35] libxl_pci: Use ev_qmp in do_pci_add"):
> > > This patch also replaces the use of
> > > libxl__wait_for_device_model_deprecated() b
Anthony PERARD writes ("[PATCH 08/35] libxl: Replace libxl__qmp_initializations
by ev_qmp calls"):
> Setup a timeout of 10s for all the commands. It used to be about 5s
> per commands.
>
> The order of command is changed, we call 'query-vnc' before
> 'change-vnc-password', but that should not mat
Anthony PERARD writes ("Re: [PATCH 08/35] libxl: Replace
libxl__qmp_initializations by ev_qmp calls"):
> On Tue, Sep 17, 2019 at 06:02:18PM +0100, Ian Jackson wrote:
> > How hard would it be to make a pre-patch to shuffle the code to the
> > same place as it's going, and change the variable names
On Wed, Sep 18, 2019 at 4:35 AM Alexandru Stefan ISAILA
wrote:
>
>
>
> On 18.09.2019 12:47, Jan Beulich wrote:
> > On 17.09.2019 17:09, Tamas K Lengyel wrote:
> >> On Tue, Sep 17, 2019 at 8:24 AM Razvan Cojocaru
> >> wrote:
> >>>
> >>> On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
>
On Tue, Sep 17, 2019 at 06:02:18PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 08/35] libxl: Replace
> libxl__qmp_initializations by ev_qmp calls"):
> > Setup a timeout of 10s for all the commands. It used to be about 5s
> > per commands.
>
> This patch is quite hard to review beca
Hi Julien,
Julien Grall writes:
> During livepatch, a single CPU will take care of applying the patch and
> all the others will wait for the action to complete. They will then once
> execute arch_livepatch_post_action() to flush the pipeline.
>
> Per B2.2.5 "Concurrent modification and execution
./configure takes a PYTHON=... argument. You can use this to specify
the python interpreter. However, for no good reason, it expects an
absolute path.
Fix this. The new logic is:
* if not set, default to `python'
* if not absolute, look it up with type -p
* split into directory and executabl
On 13.09.2019 21:27, Andrew Cooper wrote:
> @@ -1054,3 +446,191 @@ int xc_cpuid_set(
>
> return rc;
> }
> +
> +int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid,
> + const uint32_t *featureset, unsigned int
> nr_features)
> +{
> +int rc;
> +xc_dom
flight 141377 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141377/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 140282
test-armhf-armhf-
Anthony PERARD writes ("Re: [PATCH 01/35] libxl: Make libxl_domain_unpause
async"):
> I thought that HAVE_* wasn't needed when the API version is bumped. But
> now I guess that the HAVE_* macro are the only way for an application
> to build against old version of libxl since the version number isn
On Wed, Sep 18, 2019 at 3:29 AM Jan Beulich wrote:
>
> On 17.09.2019 21:31, Andrew Cooper wrote:
> > On 17/09/2019 07:15, Jan Beulich wrote:
> >> --- a/xen/arch/x86/hvm/hvm.c
> >> +++ b/xen/arch/x86/hvm/hvm.c
> >> @@ -2282,12 +2287,11 @@ int hvm_set_cr0(unsigned long value, boo
> >> return X8
Hi Linus,
please pull the dma-mapping updates for 5.4.
In addition to the usual Kconfig conflics where you just want to keep
both edits there are a few more interesting merge issues this time:
- most importanly powerpc and microblaze add new callers of
dma_atomic_pool_init, while this tree
On 18/09/2019, 12:27, "Wieczorkiewicz, Pawel" wrote:
> On 18. Sep 2019, at 13:19, Julien Grall wrote:
>
> Hi Pawel,
>
> On 18/09/2019 11:44, Wieczorkiewicz, Pawel wrote:
>>> On 18. Sep 2019, at 12:41, Ian Jackson wrote:
>>>
>>> Julien Grall writes
On Wed, Sep 18, 2019 at 11:41:13AM +0100, Paul Durrant wrote:
> ...and hence the ability to disable IOMMU mappings, and control EPT
> sharing.
>
> This patch introduces a new 'libxl_passthrough' enumeration into
> libxl_domain_create_info. The value will be set by xl either when it parses
> a new
flight 141424 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
On 9/18/19 2:52 PM, Julien Grall wrote:
During livepatch, a single CPU will take care of applying the patch and
all the others will wait for the action to complete. They will then once
execute arch_livepatch_post_action() to flush the pipeline.
Per B2.2.5 "Concurrent modification and execution o
On Tue, Sep 17, 2019 at 06:19:14PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 28/35] libxl_pci: Use ev_qmp in do_pci_add"):
> > This patch also replaces the use of
> > libxl__wait_for_device_model_deprecated() by its equivalent
> > without the need for a thread.
>
> Again, would it
On Tue, Sep 17, 2019 at 06:02:18PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 08/35] libxl: Replace
> libxl__qmp_initializations by ev_qmp calls"):
> > Setup a timeout of 10s for all the commands. It used to be about 5s
> > per commands.
>
> This patch is quite hard to review beca
On Tue, Sep 17, 2019 at 05:50:05PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 01/35] libxl: Make libxl_domain_unpause
> async"):
> > libxl_domain_unpause needs to make QMP calls, which are asynchronous,
> > change the API to reflect that.
> >
> > Do the same with libxl_domain_paus
flight 141376 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141376/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 141309
test-amd64-amd64-xl-qemut-win7-amd64
Hi,
On 19/06/2019 18:53, Volodymyr Babchuk wrote:
Volodymyr Babchuk (5):
tools/arm: tee: add "tee" option for xl.cfg
tools/arm: optee: create optee firmware node in DT if tee=optee
xen/arm: tee: place OP-TEE Kconfig option right after TEE
xen/arm: optee: check if OP-TEE is virtualiza
During livepatch, a single CPU will take care of applying the patch and
all the others will wait for the action to complete. They will then once
execute arch_livepatch_post_action() to flush the pipeline.
Per B2.2.5 "Concurrent modification and execution of instructions" in
DDI 0487E.a, flushing t
On 18.09.2019 13:36, Andrew Cooper wrote:
> On 18/09/2019 09:55, Jan Beulich wrote:
>> On 17.09.2019 15:10, Andrew Cooper wrote:
>>> On 06/08/2019 14:09, Jan Beulich wrote:
TBD: This retains prior (but suspicious) behavior of not calling
amd_iommu_set_intremap_table() for "invalid" I
On 18.09.2019 12:45, Andrew Cooper wrote:
> On 18/09/2019 09:11, Jan Beulich wrote:
>> On 17.09.2019 17:30, Andrew Cooper wrote:
>>> On 06/08/2019 14:11, Jan Beulich wrote:
There's no point setting up tables with more space than a PCI device can
use. For both MSI and MSI-X we can determin
On 18/09/2019, 12:15, "Julien Grall" wrote:
Hi Ian,
On 18/09/2019 11:41, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely
identify .rodata sections"):
>> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>>> $ scripts/./add_mai
On 18.09.2019 13:55, Andrew Cooper wrote:
> On 18/09/2019 10:22, Jan Beulich wrote:
>> On 17.09.2019 21:00, Andrew Cooper wrote:
>>> On 17/09/2019 07:14, Jan Beulich wrote:
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regar
On 18/09/2019 10:10, Jan Beulich wrote:
> On 17.09.2019 21:59, Andrew Cooper wrote:
>> On 17/09/2019 07:17, Jan Beulich wrote:
>>> PCID validly depends on LM, as it can be enabled in Long Mode only.
>>> INVPCID, otoh, can be used not only without PCID enabled, but also
>>> outside of Long Mode alto
From: Mark Syms
Some toolstack implementations will set the frontend xenstore
keys to Initialising which will then trigger the in guest PV
drivers to begin initialising and some implementations will
then set their state to Closing. If this has occurred then
device realize must not overwrite the f
When a frontend gracefully disconnects from an offline backend, it will
set its own state to XenbusStateClosed. The code in xen-block.c correctly
deals with this and sets the backend into XenbusStateClosed. Unfortunately
it is possible for toolstack to actually delete the frontend area
before the s
On 18/09/2019 10:22, Jan Beulich wrote:
> On 17.09.2019 21:00, Andrew Cooper wrote:
>> On 17/09/2019 07:14, Jan Beulich wrote:
>>> I can't see any technical or performance reason why we should treat
>>> 32-bit PV different from 64-bit PV in this regard.
>> Well, other than the fact this setting is
On 18/09/2019, 11:44, "Wieczorkiewicz, Pawel" wrote:
> On 18. Sep 2019, at 12:41, Ian Jackson wrote:
>
> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely
identify .rodata sections"):
>> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>>> $ scripts/.
On 18/09/2019 09:55, Jan Beulich wrote:
> On 17.09.2019 15:10, Andrew Cooper wrote:
>> On 06/08/2019 14:09, Jan Beulich wrote:
>>> ACPI tables are free to list far more device coordinates than there are
>>> actual devices. By delaying the table allocations for most cases, and
>>> doing them only wh
On 18/09/2019 12:27, Wieczorkiewicz, Pawel wrote:
On 18. Sep 2019, at 13:19, Julien Grall wrote:
Hi Pawel,
On 18/09/2019 11:44, Wieczorkiewicz, Pawel wrote:
On 18. Sep 2019, at 12:41, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely identify
.rod
> On 18. Sep 2019, at 13:19, Julien Grall wrote:
>
> Hi Pawel,
>
> On 18/09/2019 11:44, Wieczorkiewicz, Pawel wrote:
>>> On 18. Sep 2019, at 12:41, Ian Jackson wrote:
>>>
>>> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely
>>> identify .rodata sections"):
On 18/09/
Hi Pawel,
On 18/09/2019 11:44, Wieczorkiewicz, Pawel wrote:
On 18. Sep 2019, at 12:41, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely identify
.rodata sections"):
On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
$ scripts/./add_maintainers.pl -d
flight 141416 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
Hi Ian,
On 18/09/2019 11:41, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely identify
.rodata sections"):
On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
$ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
'-d' only tells you where the pat
From: Ian Jackson
If the end of one enum is the `type' line for the next enum, we would
not notice it.
Fix this by reordering the code, and getting rid of the else: now if
the "we are within an enum" branch decides that it's the end of the
enum, it unsets $ei and we then immediately process the
On 18/09/2019 09:11, Jan Beulich wrote:
> On 17.09.2019 17:30, Andrew Cooper wrote:
>> On 06/08/2019 14:11, Jan Beulich wrote:
>>> There's no point setting up tables with more space than a PCI device can
>>> use. For both MSI and MSI-X we can determine how many interrupts could
>>> be set up at mos
> On 18. Sep 2019, at 12:41, Ian Jackson wrote:
>
> Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely identify
> .rodata sections"):
>> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
>>> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
>>
>> '-d' only tells
From: Ian Jackson
If the end of one enum is the `type' line for the next enum, we would
not notice it.
Fix this by reordering the code, and getting rid of the else: now if
the "we are within an enum" branch decides that it's the end of the
enum, it unsets $ei and we then immediately process the
These are the remaining uncommitted patches from my previous series:
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg01208.html
The only patch that has been revised is patch #4 (previously patch #6).
Ian Jackson (1):
tools/ocaml: abi check: Cope with consecutive relevant enums
Julien Grall writes ("Re: [PATCH] create-diff-object: more precisely identify
.rodata sections"):
> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
> > $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
>
> '-d' only tells you where the patches files are. The script will look up for
Now that there is a per-domain IOMMU-enable flag, which should be set if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
destruction
...and hence the ability to disable IOMMU mappings, and control EPT
sharing.
This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
hard
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as opposed
Anthony PERARD writes ("Re: [PATCH 11/15] libxl_usb: Fix wrong usage of
asserts"):
> On Tue, Sep 17, 2019 at 05:44:03PM +0100, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH 11/15] libxl_usb: Fix wrong usage of
> > asserts"):
> > > Signed-off-by: Anthony PERARD
> >
> > I'm not sure why y
Anthony PERARD writes ("Re: [PATCH v2 3/9] libxl_internal: Introduce
libxl__ev_lock for devices hotplug via QMP"):
> On Tue, Sep 17, 2019 at 04:44:30PM +0100, Ian Jackson wrote:
> > I wonder if this is the right name for this. Effectively you have
> > called this lock "lock". Maybe "dlock" or "d
Volodymyr Babchuk writes ("[PATCH v7 1/5] tools/arm: tee: add "tee" option for
xl.cfg"):
> This enumeration controls TEE type for a domain. Currently there is
> two possible options: either 'none' or 'optee'.
>
> 'none' is the default value and it basically disables TEE support at
> all.
>
> 'op
On 18.09.2019 12:47, Jan Beulich wrote:
> On 17.09.2019 17:09, Tamas K Lengyel wrote:
>> On Tue, Sep 17, 2019 at 8:24 AM Razvan Cojocaru
>> wrote:
>>>
>>> On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
+bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t
pfec
Hi,
On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
On 18. Sep 2019, at 11:49, Jan Beulich wrote:
On 18.09.2019 09:35, Pawel Wieczorkiewicz wrote:
This is needed for more precise patchability verification.
Only non-special .rodata sections should be subject
for such a non-referenced chec
On Tue, 17 Sep 2019 at 17:31, Andrew Cooper wrote:
>
> On 16/09/2019 14:56, Paul Durrant wrote:
> >> -Original Message-
> >> From: Wei Liu
> >> Sent: 16 September 2019 14:29
> >> To: Andrew Cooper
> >> Cc: Paul Durrant ; Xen-devel
> >> ; Jan Beulich
> >> ; Wei Liu ; Roger Pau Monne
> >
On Tue, Sep 17, 2019 at 05:44:03PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH 11/15] libxl_usb: Fix wrong usage of asserts"):
> > Signed-off-by: Anthony PERARD
>
> I'm not sure why you wouldn't just delete the breaks, rather than
> replacing them "return" ?
Because asserts aren't
On Tue, Sep 17, 2019 at 04:44:30PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v2 3/9] libxl_internal: Introduce
> libxl__ev_lock for devices hotplug via QMP"):
> > The current lock `domain_userdata_lock' can't be used when modification
> > to a guest is done by sending command to Q
> On 18. Sep 2019, at 11:49, Jan Beulich wrote:
>
> On 18.09.2019 09:35, Pawel Wieczorkiewicz wrote:
>> This is needed for more precise patchability verification.
>> Only non-special .rodata sections should be subject
>> for such a non-referenced check in kpatch_verify_patchability().
>> Curren
On 18.09.2019 09:35, Pawel Wieczorkiewicz wrote:
> This is needed for more precise patchability verification.
> Only non-special .rodata sections should be subject
> for such a non-referenced check in kpatch_verify_patchability().
> Current check (non-standard, non-rela, non-debug) is too weak and
On 17.09.2019 17:09, Tamas K Lengyel wrote:
> On Tue, Sep 17, 2019 at 8:24 AM Razvan Cojocaru
> wrote:
>>
>> On 9/17/19 5:11 PM, Alexandru Stefan ISAILA wrote:
>>> +bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
>>> + uint16_t kind)
>>
On 17.09.2019 21:31, Andrew Cooper wrote:
> On 17/09/2019 07:15, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2282,12 +2287,11 @@ int hvm_set_cr0(unsigned long value, boo
>> return X86EMUL_OKAY;
>> }
>>
>> -int hvm_set_cr3(unsigned long value, bo
On 17.09.2019 21:00, Andrew Cooper wrote:
> On 17/09/2019 07:14, Jan Beulich wrote:
>> I can't see any technical or performance reason why we should treat
>> 32-bit PV different from 64-bit PV in this regard.
>
> Well, other than the fact this setting is only read for a 64bit guest...
How come? m
On 17.09.2019 21:59, Andrew Cooper wrote:
> On 17/09/2019 07:17, Jan Beulich wrote:
>> PCID validly depends on LM, as it can be enabled in Long Mode only.
>> INVPCID, otoh, can be used not only without PCID enabled, but also
>> outside of Long Mode altogether. In both cases its functionality is
>>
On 17.09.2019 21:35, Andrew Cooper wrote:
> On 17/09/2019 07:15, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1004,6 +1004,13 @@ static int hvm_load_cpu_ctxt(struct doma
>> return -EINVAL;
>> }
>>
>> +if ( ctxt.cr3 >> d->arch.cpuid->e
On 17.09.2019 15:10, Andrew Cooper wrote:
> On 06/08/2019 14:09, Jan Beulich wrote:
>> ACPI tables are free to list far more device coordinates than there are
>> actual devices. By delaying the table allocations for most cases, and
>> doing them only when an actual device is known to be present at
On 17.09.2019 17:30, Andrew Cooper wrote:
> On 06/08/2019 14:11, Jan Beulich wrote:
>> There's no point setting up tables with more space than a PCI device can
>> use. For both MSI and MSI-X we can determine how many interrupts could
>> be set up at most. Tables allocated during ACPI table parsing,
> -Original Message-
> From: George Dunlap
> Sent: 16 September 2019 11:15
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Christian Lindig
> ; Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ;
> Konrad Rzeszutek Wilk
> ; Stefano Stabel
On 17.09.2019 17:39, Alexandru Stefan ISAILA wrote:
> On 17.09.2019 18:04, Jan Beulich wrote:
>> On 17.09.2019 17:00, Alexandru Stefan ISAILA wrote:
>>> There is no problem, I understand the risk of having suspicious return
>>> values. I am not hanged on having this return. I used this to skip
>>>
This is needed for more precise patchability verification.
Only non-special .rodata sections should be subject
for such a non-referenced check in kpatch_verify_patchability().
Current check (non-standard, non-rela, non-debug) is too weak and
allows also non-rodata sections without referenced symbol
flight 141413 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141413/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253
Tests which
93 matches
Mail list logo
