Re: [Xen-devel] [PATCH 2/3] x86/HVM: limit writes to outgoing TSS during task switch

>>> On 22.11.16 at 17:46, wrote: > On 22/11/16 13:55, Jan Beulich wrote: >> The only fields modified are EIP, EFLAGS, GPRs, and segment selectors. >> CR3 in particular is not supposed to be updated. >> >> Signed-off-by: Jan Beulich >> >> ---

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

>>> On 23.11.16 at 00:47, wrote: > I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with > XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to > perform two (or more, if >32 VCPUs) hypercalls and the logic on the > hypervisor side is

Re: [Xen-devel] [PATCH 1/3] x86/HVM: limit writes to incoming TSS during task switch

>>> On 22.11.16 at 17:32, wrote: > On 22/11/16 13:55, Jan Beulich wrote: >> The only field modified (and even that conditionally) is the back link. >> Write only that field, and only when it actually has been written to. >> >> Take the opportunity and also ditch the

[Xen-devel] [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

v2: * Changes suggested by Laszlo: - change the catch-all (*) to GCC5, from GCC44 - remove the (5.*.*) pattern from GCC49 - generate error for GCC < 4.4 In v3, also generate error for really GCC < 4.4, like GCC 1. Reviewed-by: Laszlo Ersek Reviewed-by: Jordan Justen

[Xen-devel] PATCH v3] Compile TianoCore under Fedora Core 25

Hey! Changelog: v3: It is perfect! - Redid commit per Jordan suggestion - Redid the failure scenario per Laszlo suggestion - Redid the testing v2: - Redid it per Laszlo suggestion, added the URL to the bugzilla system - Tested it under more OSes This patch allows me to compile TianoCore

Re: [Xen-devel] Xen virtual IOMMU high level design doc

> From: Stefano Stabellini [mailto:sstabell...@kernel.org] > Sent: Thursday, November 24, 2016 3:09 AM > > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote: > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > > > Hi All: > > > The following is our Xen vIOMMU high level design for

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 21:44:50 MEZ, schrieb Olaf Hering : >Is this a can for 2.x? candidate Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Problems with livepatching

On 23/11/2016 23:06, M A Young wrote: > I have been experimenting with live patching with the recent batch of > security updates on Fedora xen with very limited success. I had most > attempts with a test build of xen-4.8.0-rc6, and of the updates I have > tried only xsa192.patch uploads

[Xen-devel] [qemu-upstream-unstable test] 102534: tolerable FAIL - PUSHED

flight 102534 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102534/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 101634

Re: [Xen-devel] Problems with livepatching

On Wed, 23 Nov 2016, Andrew Cooper wrote: > On 23/11/2016 23:06, M A Young wrote: > > I have been experimenting with live patching with the recent batch of > > security updates on Fedora xen with very limited success. I had most > > attempts with a test build of xen-4.8.0-rc6, and of the

[Xen-devel] [qemu-upstream-4.7-testing test] 102532: regressions - FAIL

flight 102532 qemu-upstream-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102532/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 100711

[Xen-devel] Problems with livepatching

I have been experimenting with live patching with the recent batch of security updates on Fedora xen with very limited success. I had most attempts with a test build of xen-4.8.0-rc6, and of the updates I have tried only xsa192.patch uploads successfully. For example with xsa191.patch the

Re: [Xen-devel] Problems with livepatching

On Thu, Nov 24, 2016 at 12:13:43AM +, M A Young wrote: > On Wed, 23 Nov 2016, Andrew Cooper wrote: > > > On 23/11/2016 23:06, M A Young wrote: > > > I have been experimenting with live patching with the recent batch of > > > security updates on Fedora xen with very limited success. I had

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS] create-diff-object: Update fixup offsets in .rela.ex_table

From: Ross Lagerwall When pruning entries from the fixup table, update the offsets in .rela.ex_table otherwise the relas might point to the wrong fixup entry or even out of the .fixup section. Signed-off-by: Ross Lagerwall Signed-off-by:

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > and move it to live with the other x86_event infrastructure in x86_emulate.h. > Switch it and x86_event.error_code to being signed, matching the rest of the > code. > > Signed-off-by:

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > The emulator needs to gain an understanding of interrupts and exceptions > generated by its actions. > > Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they > are

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On Thu, Nov 24, 2016 at 02:00:21AM +, Tian, Kevin wrote: > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: Thursday, November 24, 2016 3:09 AM > > > > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote: > > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote: > > > >

Re: [Xen-devel] [PATCH 12/15] x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > The functions use linear addresses, not virtual addresses, as no segmentation > is used. (Lots of other code in Xen makes this mistake.) > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > which is filled with pagefault information should one occur. > > No functional change. > > Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich

[Xen-devel] [libvirt test] 102550: regressions - FAIL

flight 102550 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/102550/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 16 debian-fixup/dst_hostfail REGR. vs. 102503 Regressions which are

[Xen-devel] [xen-4.7-testing test] 102536: tolerable FAIL - PUSHED

flight 102536 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102536/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail in 102518 pass in 102536 test-armhf-armhf-xl-xsm

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

On 2016年11月22日 18:24, Jan Beulich wrote: On 17.11.16 at 16:36, wrote: >> 2) Build ACPI DMAR table in toolstack >> Now tool stack can boot ACPI DMAR table according VM configure and pass >> though it to hvmloader via xenstore ACPI PT channel. But the vIOMMU MMIO >>

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are >very closely related. > * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and >

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > The x86 emulator needs to gain an understanding of interrupts and exceptions > generated by its actions. The naming choice is to match both the Intel and > AMD terms, and to avoid 'trap'

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > Intel VT-x and AMD SVM provide access to the full segment descriptor cache via > fields in the VMCB/VMCS. However, the bits which are actually checked by > hardware and preserved across

Re: [Xen-devel] Big.LITTLE support (WAS Re: Xen ARM community call)

Hi Julien, On Tue, Nov 22, 2016 at 02:28:39PM +, Julien Grall wrote: >Hello Anastassios, > >On 09/11/16 22:50, Anastassios Nanos wrote: >>Hi Julien, all, >> >>>I would like to start organizing a recurring community call to discuss and >>>sync-up on upcoming features for Xen ARM. >> >>great

[Xen-devel] [xen-unstable baseline-only test] 68086: tolerable FAIL

This run is configured for baseline tests only. flight 68086 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68086/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-4 10 xtf-fep

Re: [Xen-devel] [PATCH 07/15] x86/vmx: Use hvm_{get, set}_segment_register() rather than vmx_{get, set}_segment_register()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 23, 2016 11:39 PM > > No functional change at this point, but this is a prerequisite for forthcoming > functional changes. > > Make vmx_get_segment_register() private to vmx.c like all the other Vendor > get/set

Re: [Xen-devel] Xen virtual IOMMU high level design doc

On 2016年11月24日 12:09, Edgar E. Iglesias wrote: Hi, > > > > > > I have a few questions. > > > > > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen. > > > So guests will essentially create intel iommu style page-tables. > > > > > > If we

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 68087: regressions - FAIL

This run is configured for baseline tests only. flight 68087 qemu-upstream-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68087/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run:

[Xen-devel] [xen-4.5-testing test] 102543: regressions - FAIL

flight 102543 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102543/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275

[Xen-devel] [ovmf test] 102546: all pass - PUSHED

flight 102546 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102546/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0265811dbe56cf46fb3c152b2ccdefd8fb47a170 baseline version: ovmf

[Xen-devel] [PATCH v2] xen_disk: split discard input to match internal representation

The guest sends discard requests as u64 sector/count pairs, but the block layer operates internally with s64/s32 pairs. The conversion leads to IO errors in the guest, the discard request is not processed. domU.cfg: 'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2' domU:

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

Ping. On Fri, Nov 18, Olaf Hering wrote: > On Fri, Nov 18, Olaf Hering wrote: > > > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > > +if (!blk_split_discard(ioreq, req->sector_number, > > req->nr_sectors)) { > > +goto err; > > How is error

[Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

We should not consume the second slot if it didn't get written yet. Normal writers - i.e. Xen - would not update write_pointer between the two writes, but the page may get fiddled with by the guest itself, and we're better off entering an infinite loop in that case. Reported-by: yanghongke

[Xen-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling

There's no point setting fields always receiving the same value on each iteration, as handle_ioreq() doesn't alter them anyway. Set state and count once ahead of the loop, drop the redundant clearing of data_is_ptr, and avoid the meaningless setting of df altogether. Also avoid doing an unsigned

Re: [Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

On 23/11/2016 09:43, Jan Beulich wrote: On 23.11.16 at 05:11, wrote: >> flight 102519 xen-4.6-testing real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/102519/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 23 November 2016 09:24 > To: qemu-de...@nongnu.org > Cc: Anthony Perard ; Paul Durrant > ; Stefano Stabellini ; xen- > devel

Re: [Xen-devel] [Qemu-devel] [PATCH v2] xen_disk: split discard input to match internal representation

Hi, Your series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH v2] xen_disk: split discard input to match internal representation Type: series Message-id: 20161123094914.15675-1-o...@aepfle.de === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs

Hi, static DECLARE_BITMAP(vmid_mask, MAX_VMID); >> >> void p2m_vmid_allocator_init(void) >> { >> +unsigned int cpu; >> + >> set_bit(INVALID_VMID, vmid_mask); >> + >> +max_vmid = MAX_VMID; >> > > max_vmid is only declared for ARM64 and will break compilation for ARM32. > Please

Re: [Xen-devel] XEN tools for ARM64 build issue

>>> On 23.11.16 at 11:29, wrote: > Building latest XEN master branch > (58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using > the same yocto as here > https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X > I've > faced following

Re: [Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

>>> On 23.11.16 at 05:11, wrote: > flight 102519 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/102519/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 23 November 2016 09:25 > To: qemu-de...@nongnu.org > Cc: Anthony Perard ; Paul Durrant > ; Stefano Stabellini ; xen- > devel

[Xen-devel] [xen-unstable-coverity test] 102559: all pass - PUSHED

flight 102559 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/102559/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 986f790e0184d4bf575462077378e14fa9f85aa9 baseline version: xen

[Xen-devel] XEN tools for ARM64 build issue

Dear all, Building latest XEN master branch (58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using the same yocto as here https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X I've faced following issue: Maximum error count (200) exceeded

[Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

The guest sends discard requests as u64 sector/count pairs, but the block layer operates internally with s64/s32 pairs. The conversion leads to IO errors in the guest, the discard request is not processed. domU.cfg: 'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2' domU:

[Xen-devel] [PATCH] x86emul: CMOVcc always writes its destination

This would be benign if there wasn't the zero-extending side effect of 32-bit operations in 64-bit mode. Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -653,6 +653,21 @@ int main(int argc,

Re: [Xen-devel] [PATCH 3/3] x86/HVM: correct error code writing during task switch

>>> On 22.11.16 at 17:58, wrote: > On 22/11/16 13:56, Jan Beulich wrote: >> Whether to write 32 or just 16 bits depends on the D bit of the target >> CS. The width of the stack pointer to use depends on the B bit of the >> target SS. >> >> Also avoid using the no-fault

[Xen-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling

There's no way to communicate back read data, so only writes can ever be usefully specified. Ignore the field, paving the road for eventually re-using the bit for something else in a few (many?) years time. Signed-off-by: Jan Beulich --- a/xen-hvm.c +++ b/xen-hvm.c @@ -997,6

Re: [Xen-devel] XEN tools for ARM64 build issue

> Looking at the source I see that this statement gets included for > x86 only. Are you perhaps doing a cross build of the ARM tools > on an x86 host? Indeed. I do. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Wed, Nov 23, Olaf Hering wrote: > > > +if (!blk_split_discard(ioreq, req->sector_number, > > > req->nr_sectors)) { > > > +goto err; > > How is error handling supposed to work here? In the guest the cmd is stuck, instead of getting an IO error: [ 91.966404] mkfs.ext4

Re: [Xen-devel] [xen-4.6-testing test] 102519: regressions - FAIL

>>> On 23.11.16 at 10:49, wrote: > The invlpg logic isn't (or is no longer) squashing segmentation faults. > > I can't recall whether you backported the change that far, but it looks > as if the test might accidentally been relying on XSA-191 to function on > older

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

>>> On 23.11.16 at 11:45, wrote: > No, if QEMU is using a default ioreq server (i.e. the legacy way of doing > things) then it's vulnerable to the guest messing with the rings and I'd > forgotten that migrated-in guests from old QEMUs also end up using the > default >

Re: [Xen-devel] [PATCH 1/2] build system: Include SeaBIOS and TianoCore directory

On Tue, Nov 22, 2016 at 11:02:04PM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote: > > On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk wrote: > > > The release source did not include those two directories. > > > > > > Signed-off-by:

[Xen-devel] [patch added to 3.12-stable] x86/mm/xen: Suppress hugetlbfs in PV guests

From: Jan Beulich This patch has been added to the 3.12 stable tree. If you have any objections, please let us know. === commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream. Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use

Re: [Xen-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 23 November 2016 09:25 > To: qemu-de...@nongnu.org > Cc: Anthony Perard ; Paul Durrant > ; Stefano Stabellini ; xen- > devel

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

>>> On 23.11.16 at 10:48, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 23 November 2016 09:24 >> >> We should not consume the second slot if it didn't get written yet. >> Normal writers - i.e. Xen - would not update write_pointer between the >> two

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 23 November 2016 10:36 > To: Paul Durrant > Cc: Anthony Perard ; Stefano Stabellini > ; xen-devel ; >

[Xen-devel] [PATCH 0/3] xen: XSA-197 follow-ups

1: fix quad word bufioreq handling 2: slightly simplify bufioreq handling 3: ignore direction in bufioreq handling Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

On Mon, Nov 21, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Tested-by: Olaf Hering This should go to stable as well. Olaf

Re: [Xen-devel] [PATCH 1/3] x86/HVM: limit writes to incoming TSS during task switch

On 23/11/16 08:27, Jan Beulich wrote: On 22.11.16 at 17:32, wrote: >> On 22/11/16 13:55, Jan Beulich wrote: >>> The only field modified (and even that conditionally) is the back link. >>> Write only that field, and only when it actually has been written to. >>> >>>

Re: [Xen-devel] [PATCH 1/2] build system: Include SeaBIOS and TianoCore directory

On November 23, 2016 5:14:00 AM EST, Wei Liu wrote: >On Tue, Nov 22, 2016 at 11:02:04PM -0500, Konrad Rzeszutek Wilk wrote: >> On Wed, Nov 23, 2016 at 02:39:35AM +, Wei Liu wrote: >> > On Sun, Nov 20, 2016 at 10:27:21PM -0500, Konrad Rzeszutek Wilk >wrote: >> > > The

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23.11.2016 um 12:40 hat Eric Blake geschrieben: > On 11/23/2016 04:39 AM, Olaf Hering wrote: > > The guest sends discard requests as u64 sector/count pairs, but the > > block layer operates internally with s64/s32 pairs. The conversion > > leads to IO errors in the guest, the discard request is

Re: [Xen-devel] [PATCH] xen/arm: Add support for 16 bit VMIDs

On 23/11/16 10:38, Bhupinder Thakur wrote: Hi, Hi Bhupinder, Can you configure your e-mail client to use ">" to quote the previous answer? Using tab makes the mail quite confusing. Thank you. static DECLARE_BITMAP(vmid_mask, MAX_VMID); void

Re: [Xen-devel] [PATCH v2 XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

On Wed, Nov 23, 2016 at 12:27:38PM +, Roger Pau Monne wrote: > Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit > guests, that corrupted the section headers array due to the padding > introduced by the elf_shdr union. > > The Elf section header array on 32bit should be

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 03:03:54PM +0200, Andrii Anisov wrote: > > This will not work because Kconfig support only exists for the hypervisor. > > So I totally confused where CONFIG_ARM_64 is defined for tools. > It is defined in config/arm64.mk, which is included by various makefiles. >

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

On 11/23/2016 03:09 AM, Jan Beulich wrote: On 23.11.16 at 00:47, wrote: >> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with >> XEN_DOMCTL_acpi_access and it seems to work OK. The toolstack needs to >> perform two (or more, if >32 VCPUs)

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> But before you write any code, let me try to understand the real issue > first: you're trying to cross-build ARM tools on x86, but x86 > iasl doesn't support ARM ACPI definition(s), right? Well, as I stated here [1], I'm pretty far from ACPI and understanding of what's going wrong with the

[Xen-devel] [distros-debian-squeeze test] 68084: tolerable FAIL

flight 68084 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68084/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 68048

[Xen-devel] [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status

EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to compare it against xen_vcpu_id mapping, not the Linux cpu id. Suggested-by: Radim Krcmar Signed-off-by: Vitaly Kuznetsov --- drivers/xen/events/events_base.c | 2 +- 1 file changed, 1

[Xen-devel] [xen-4.4-testing baseline-only test] 68083: tolerable FAIL

This run is configured for baseline tests only. flight 68083 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68083/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl19

Re: [Xen-devel] [PATCH 0/3] x86/HVM: XSA-192 follow-ups

On Tue, Nov 22, 2016 at 06:51:27AM -0700, Jan Beulich wrote: > 1: limit writes to incoming TSS during task switch > 2: limit writes to outgoing TSS during task switch > 3: correct error code writing during task switch > > Signed-off-by: Jan Beulich > Release-acked-by: Wei

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Iurii, About the following: > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix > build issue, described here [2]. I haven't found any better solution except > this one. Please review this [1] thread. [1]

Re: [Xen-devel] [PATCH 0/2] x86emul: recent XSA follow-up

On Tue, Nov 22, 2016 at 07:09:04AM -0700, Jan Beulich wrote: > These aren't outright bug fixes, so aren't strictly candidates for 4.8, > but I think they're still worthwhile to consider. > > 1: simplify DstBitBase handling code > 2: in_longmode() should not ignore ->read_msr() errors > >

Re: [Xen-devel] [RFC] Shared coprocessor framework

Stefano, Please see my answers below: > > Thank you for the document, I think is a very good start. I also see the > need for this framework. Please add more details about the proposed > interface (Xen API, hypercalls, etc) in the next version; I am looking > forward to it. We will come up with

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

>>> On 23.11.16 at 14:33, wrote: > On 11/23/2016 03:09 AM, Jan Beulich wrote: > On 23.11.16 at 00:47, wrote: >>> I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with >>> XEN_DOMCTL_acpi_access and it seems to work OK. The

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Dear all, Andrii, thanks for the remark - I'll rework this patch. Julien, I have updated yocto layer [1] to use the most recent stable Xen version - Xen 4.8-rc6 Looks like used patches for Xen should be described more briefly: 1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 03:59:54PM +0200, Andrii Anisov wrote: > > It is defined in config/arm64.mk, which is included by various > > makefiles. > As I got, it is included by Config.mk which consequently included by > different makefiles in hypervisor, tools, docs, stubdom. > It looks like a piece

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

On 11/23/2016 04:39 AM, Olaf Hering wrote: > The guest sends discard requests as u64 sector/count pairs, but the > block layer operates internally with s64/s32 pairs. The conversion > leads to IO errors in the guest, the discard request is not processed. > > domU.cfg: > 'vdev=xvda,

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> It is defined in config/arm64.mk, which is included by various > makefiles. As I got, it is included by Config.mk which consequently included by different makefiles in hypervisor, tools, docs, stubdom. It looks like a piece of legasy configuration code, I see moves of CONFIG_ options from it to

[Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Make the libxl ACPI support build configurable by the same config option as the hypervisor side support. Signed-off-by: Andrii Anisov --- tools/libxl/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile

[Xen-devel] [PATCH v2 XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

From: Roger Pau Monne Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit guests, that corrupted the section headers array due to the padding introduced by the elf_shdr union. The Elf section header array on 32bit should be accessible as an array of

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> This will not work because Kconfig support only exists for the hypervisor. So I totally confused where CONFIG_ARM_64 is defined for tools. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

On 11/23/2016 08:58 AM, Jan Beulich wrote: On 23.11.16 at 14:33, wrote: >> On 11/23/2016 03:09 AM, Jan Beulich wrote: >> On 23.11.16 at 00:47, wrote: I have a prototype that replaces XEN_DOMCTL_set_avail_vcpus with

[Xen-devel] [PATCH RFC] docs/designs: PV stats interface

This patch introduces a design proposal for an interface to used by guest PV drivers or agents to convey statistics to a monitoring agent running in a toolstack domain. Signed-off-by: Paul Durrant --- RFC at the moment since this is a first draft and it is not yet

[Xen-devel] [PATCH v5 0/3] Significant changes to Xen Project Governance (governance.html) - COMMITTERS PLEASE VOTE ON THE PROPOSAL

THIS IS VERSION 5 OF THIS PATCH AND WE ARE READY FOR FORMAL VOTING, UNLESS SOMEONE OBJECTS. PEOPLE LISTED AS COMMITTERS IN - https://xenproject.org/developers/teams/hypervisor.html - https://xenproject.org/developers/teams/xapi.html PLEASE VOTE BEFORE DEC 2nd I made some significant proposed

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Hello, On 23/11/16 12:25, Andrii Anisov wrote: Make the libxl ACPI support build configurable by the same config option as the hypervisor side support. This will not work because Kconfig support only exists for the hypervisor. Furthermore, people may want to disable ACPI for the host but

[Xen-devel] [PATCH v2 XSA-followup for-4.8] libelf: fix symtab/strtab loading for 32bit domains

Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit guests, that corrupted the section headers array due to the padding introduced by the elf_shdr union. The Elf section header array on 32bit should be accessible as an array of Elf32_Shdr elements, and the union with Elf64_Shdr

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Dear Iurii, Following: > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix > build issue, described here [2]. I haven't found any better solution except > this one. Is not needed. The issue does not appear with the current master HEAD. Sincerely, Andrii Anisov. On Wed,

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

>>> On 23.11.16 at 15:05, wrote: > But before you write any code, let me try to understand the real issue > first: you're trying to cross-build ARM tools on x86, but x86 > iasl doesn't support ARM ACPI definition(s), right? No, the problem is that Shannon has broken cross

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

On Wed, Nov 23, 2016 at 02:34:04PM +, Julien Grall wrote: > Hi Wei, > > On 23/11/16 14:29, Wei Liu wrote: > >On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote: > >>>But before you write any code, let me try to understand the real issue > >>>first: you're trying to cross-build ARM

Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface

> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: 23 November 2016 15:08 > To: Paul Durrant ; annie...@oracle.com; > adnan.mishe...@oracle.com > Cc: xen-de...@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH RFC]

[Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

The emulator needs to gain an understanding of interrupts and exceptions generated by its actions. Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they are visible to the emulator. This removes the need for the inject_{hw,sw}_interrupt() hooks, which are dropped and

[Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

which is filled with pagefault information should one occur. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Paul Durrant CC: Tim Deegan CC: Jun Nakajima

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Hello Julien, > The ACPI support is pretty much contained in a single file and I am not sure > you will win much space. > Can you explain why the ACPI guest support should be optional? This would increase the system configurability and would let one shrink a system to a minimal footprint with

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 23 November 2016 15:39 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich > ; Paul Durrant ; Jun > Nakajima

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Dear Andrii and all, On Wed, Nov 23, 2016 at 4:15 PM, Andrii Anisov wrote: > Iurii, > > About the following: > > > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix > > build issue, described here [2]. I haven't found any better solution > except >

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Hi Wei, On 23/11/16 14:29, Wei Liu wrote: On Wed, Nov 23, 2016 at 04:12:28PM +0200, Andrii Anisov wrote: But before you write any code, let me try to understand the real issue first: you're trying to cross-build ARM tools on x86, but x86 iasl doesn't support ARM ACPI definition(s), right?

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

On 23/11/16 14:00, Iurii Mykhalskyi wrote: Dear all, Hello Iurii, Julien, I have updated yocto layer [1] to use the most recent stable Xen version - Xen 4.8-rc6 Can you explain why you want to impose a specific version of Xen to the user of this board? If Xen does not work out-of-box

Re: [Xen-devel] [PATCH RFC] docs/designs: PV stats interface

On Wed, Nov 23, 2016 at 02:14:27PM +, Paul Durrant wrote: > This patch introduces a design proposal for an interface to used by > guest PV drivers or agents to convey statistics to a monitoring agent > running in a toolstack domain. > Hey Paul! Thank you for posting this, adding on the CC

  1   2   >