[Xen-devel] [qemu-upstream-4.3-testing test] 96078: regressions - FAIL

flight 96078 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96078/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

On 21/06/16 17:52, Boris Ostrovsky wrote: > On 06/21/2016 10:37 AM, Andrey Grodzovsky wrote: >> Current overlap check is evaluating to false a case where a filter field >> is fully contained (proper subset) of a r/w request. >> This change applies classical overlap check instead to include >> all

[Xen-devel] sunxi U-boot Branch

Hi All, I am trying to build u-boot for cubieboards A20 with hypervisor support. Eventually i will installing and loading xen in this board. I couldn't find *sunxi-next* branch that include hypervisor support in current git repo ( git://github.com/jwrdegoede/u-boot-sunxi.git). Please let me

[Xen-devel] [xen-4.3-testing bisection] complete build-i386-libvirt

branch xen-4.3-testing xenbranch xen-4.3-testing job build-i386-libvirt testid libvirt-build Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions

On 2016/6/6 20:16, Wei Liu wrote: > On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote: >> > >> > >> > On 2016/6/6 18:11, Julien Grall wrote: >>> > > Hi Stefano, >>> > > >>> > > On 06/06/2016 11:04, Stefano Stabellini wrote: > >> On Tue, 31 May 2016, Shannon Zhao wrote: > >

Re: [Xen-devel] [PATCH v9 1/3] vt-d: fix the IOMMU flush issue

On June 21, 2016 9:25 PM, Jan Beulich wrote: > >>> On 17.06.16 at 05:37, wrote: > > @@ -546,17 +550,37 @@ static int __must_check iommu_flush_all(void) > > struct acpi_drhd_unit *drhd; > > struct iommu *iommu; > > int flush_dev_iotlb; > > +

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

On 06/21/2016 09:53 AM, George Dunlap wrote: > On 21/06/16 16:11, Ian Jackson wrote: >> Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"): >>> Here is what we have gathered so far: >> ... >>> We can, however, just make recommendation that system administrators can >>>

[Xen-devel] [ovmf test] 96050: regressions - FAIL

flight 96050 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96050/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748

[Xen-devel] [xen-unstable-smoke test] 96074: tolerable all pass - PUSHED

flight 96074 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/96074/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

[Xen-devel] [xen-unstable test] 96049: tolerable FAIL - PUSHED

flight 96049 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/96049/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 95980 build-i386-rumpuserxen

[Xen-devel] [qemu-upstream-4.3-testing test] 96052: regressions - FAIL

flight 96052 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96052/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927

Re: [Xen-devel] [PATCH v2] x86/HVM: use available linear->phys translations in REP MOVS/STOS handling

On 20/06/16 12:29, Jan Beulich wrote: > If we have the translation result available already, we should also use > it here. In my tests with Linux guests this eliminates all calls to > hvmemul_linear_to_phys() from the STOS path and most from the MOVS one. > > Also record the translation for re-use

[Xen-devel] [xen-unstable-smoke test] 96071: regressions - FAIL

flight 96071 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/96071/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 96064 Tests which

Re: [Xen-devel] [PATCHv2] x86/xen: avoid m2p lookup when setting early page table entries

On 06/21/2016 12:09 PM, David Vrabel wrote: > When page tables entries are set using xen_set_pte_init() during early > boot there is no page fault handler that could handle a fault when > performing an M2P lookup. > > In 64 guest (usually dom0) early_ioremap() would fault in > xen_set_pte_init()

[Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

Current overlap check is evaluating to false a case where a filter field is fully contained (proper subset) of a r/w request. This change applies classical overlap check instead to include all the scenarios. More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device driver the logic is such

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

On Tue, Jun 21, 2016 at 1:15 PM, David Vrabel wrote: > On 21/06/16 15:37, Andrey Grodzovsky wrote: > > Current overlap check is evaluating to false a case where a filter field > > is fully contained (proper subset) of a r/w request. > > This change applies classical

Re: [Xen-devel] [PATCH] x86: compact supposedly unused entry point code

On 20/06/16 15:04, Jan Beulich wrote: On 20.06.16 at 15:58, wrote: >> On 20/06/16 14:49, Jan Beulich wrote: >> On 20.06.16 at 14:54, wrote: On 20/06/16 13:48, Jan Beulich wrote: On 20.06.16 at 14:15,

Re: [Xen-devel] [PATCH 4/4] x86/vMSI-X: use generic intercept handler in place of MMIO one

On 08/06/16 13:54, Jan Beulich wrote: > This allows us to see the full ioreq without having to peek into state > which is supposedly private to the emulation framework. > > Suggested-by: Paul Durrant > Signed-off-by: Jan Beulich Reviewed-by: Andrew

Re: [Xen-devel] [PATCH 3/4] x86/vMSI-X: drop pci_msix_get_table_len()

On 08/06/16 13:54, Jan Beulich wrote: > We can calculate the needed value at the single use site more easily. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 2/4] x86/vMSI-X: drop list lock

On 08/06/16 13:53, Jan Beulich wrote: > msixtbl_pt_{,un}register() already run with both the PCI devices lock > and the domain event lock held, so there's no need for another lock. > Just to be on the safe side, acquire the domain event lock in the > cleanup function (albeit I don't think this is

Re: [Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

On 21/06/16 18:19, Konrad Rzeszutek Wilk wrote: > On Tue, Jun 21, 2016 at 05:59:04PM +0100, Andrew Cooper wrote: >> Its contents is constant. >> > Could you mention why you don't need the ALIGN(32). Because there is no content following it, before a larger alignment. ~Andrew

Re: [Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

On Tue, Jun 21, 2016 at 05:59:04PM +0100, Andrew Cooper wrote: > Its contents is constant. > Could you mention why you don't need the ALIGN(32). Thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] arm/init: Move .init.proc.info into .init.data

On Tue, Jun 21, 2016 at 05:59:03PM +0100, Andrew Cooper wrote: > Its contents is constant, and only requires pointer alignment, so move it > adacent to .init.setup. adjacent with that Reviewed-by: Konrad Rzeszutek Wilk ___

[Xen-devel] [xen-unstable-smoke test] 96064: tolerable all pass - PUSHED

flight 96064 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/96064/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

On 21/06/16 15:37, Andrey Grodzovsky wrote: > Current overlap check is evaluating to false a case where a filter field > is fully contained (proper subset) of a r/w request. > This change applies classical overlap check instead to include > all the scenarios. Reviewed-by: David Vrabel

Re: [Xen-devel] [PATCH 1/4] x86/vMSI-X: defer intercept handler registration

On 08/06/16 13:52, Jan Beulich wrote: > There's no point in registering the internal MSI-X table intercept > functions on all domains - it is sufficient to do so once a domain gets > an MSI-X capable device assigned. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH 13/17 v3] xen: move FLASK entry under XSM in Kconfig

Since enabling XSM is required to enable FLASK, place the option for FLASK below the one for XSM. In addition, since it does not make sense to enable XSM without any XSM providers, and FLASK is the only XSM provider, hide the option to disable FLASK under EXPERT. Signed-off-by: Daniel De Graaf

[Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

Its contents is constant. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Stefano Stabellini CC: Julien Grall v2: * New --- xen/arch/arm/xen.lds.S | 14 ++ xen/arch/x86/xen.lds.S |

[Xen-devel] [PATCH v2 2/4] arm/init: Move .init.proc.info into .init.data

Its contents is constant, and only requires pointer alignment, so move it adacent to .init.setup. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall v2: * New --- xen/arch/arm/xen.lds.S | 9

[Xen-devel] [PATCH v2 4/4] x86/boot: copy/clear sections more efficiently

Both the trampoline copy and BSS initialise can be performed more efficiently by using 4-byte variants of the string operations. On Intel systems with ERMSB (efficient rep movsb), this is no practical difference. On all other systems, this is 4 times more efficient. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v2 1/4] xen/init: Annotate all command line parameter infrastructure as const

There is no reason for any of it to be modified. Additionally, link .init.setup beside the other constant .init data. While editing this area, correct the types used in the extern declarations for __setup_start and __setup_end to match the types the linker actually produces. No functional

[Xen-devel] [PATCH v1 Altp2m cleanup 0/3] Cleaning up altp2m code

Cleaning up altp2m code per request of xen-devel mailing list. Paul Lai (3): altp2m cleanup work Move altp2m specific functions to altp2m files. Making altp2m struct dynamically allocated. xen/arch/x86/hvm/hvm.c| 41 ++-- xen/arch/x86/hvm/vmx/vmx.c| 2 +-

Re: [Xen-devel] [PATCH 03/19] xen: credit2: insert and tickle don't need a cpu parameter

On 18/06/16 00:11, Dario Faggioli wrote: In fact, they always operate on the svc->processor of the csched2_vcpu passed to them. No functional change intended. Signed-off-by: Dario Faggioli Reviewed-by: Anshul Makkar --- Cc: George

[Xen-devel] [PATCH v1 Altp2m cleanup 2/3] Move altp2m specific functions to altp2m files.

Move altp2m specific functions to altp2m files. This makes the code a little easier to read. Signed-off-by: Paul Lai --- xen/arch/x86/mm/altp2m.c | 43 +++ xen/arch/x86/mm/hap/hap.c | 35 +--

[Xen-devel] [PATCH v1 Altp2m cleanup 3/3] Making altp2m struct dynamically allocated.

Ravi Sahita's dynamically allocated altp2m structs Signed-off-by: Paul Lai --- xen/arch/x86/hvm/hvm.c | 8 +++--- xen/arch/x86/hvm/vmx/vmx.c | 2 +- xen/arch/x86/mm/altp2m.c | 18 +++--- xen/arch/x86/mm/mm-locks.h | 4 +-- xen/arch/x86/mm/p2m-ept.c

[Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work

Indent goto labels by one space Inline (header) altp2m functions Define default behavior in switch Define max and min for range of altp2m macroed values Signed-off-by: Paul Lai --- xen/arch/x86/hvm/hvm.c | 33 +

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

On 21/06/16 17:04, Ian Jackson wrote: > My point was that I think we should decide first what our proposed > solution will look like, and _then_ whether it should be in libxlu or > libxl. Indeed. I agree that direct consumers of xl are an important "market segment" that we need to support. I'd

Re: [Xen-devel] [PATCH 01/19] xen: sched: leave CPUs doing tasklet work alone.

On 18/06/16 00:11, Dario Faggioli wrote: In both Credit1 and Credit2, stop considering a pCPU idle, if the reason why the idle vCPU is being selected, is to do tasklet work. Not doing so means that the tickling and load balancing logic, seeing the pCPU as idle, considers it a candidate for

[Xen-devel] [PATCHv2] x86/xen: avoid m2p lookup when setting early page table entries

When page tables entries are set using xen_set_pte_init() during early boot there is no page fault handler that could handle a fault when performing an M2P lookup. In 64 guest (usually dom0) early_ioremap() would fault in xen_set_pte_init() because an M2P lookup faults because the MFN is in MMIO

Re: [Xen-devel] [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section

On 21/06/16 16:41, Julien Grall wrote: > Hello, > > On 21/06/16 16:21, Andrew Cooper wrote: >> On 20/06/16 15:04, Daniel De Graaf wrote: >>> Since FLASK is the only implementation of XSM hooks in Xen, using an >>> iterated initcall dispatch for setup is overly complex. Change this to >>> a direct

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

George Dunlap writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"): > I think that having the option to pass an fd in would be useful and will > probably be wanted at some point; I think libvirt for instance should > probably be modified to use such an interface once it's available

[Xen-devel] [xen-4.3-testing test] 96042: regressions - FAIL

flight 96042 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96042/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 87893

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

On 21/06/16 16:11, Ian Jackson wrote: > Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"): >> Here is what we have gathered so far: > ... >> We can, however, just make recommendation that system administrators can >> easily set up and call it a day. There are suggestions

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

On 06/21/2016 10:37 AM, Andrey Grodzovsky wrote: > Current overlap check is evaluating to false a case where a filter field > is fully contained (proper subset) of a r/w request. > This change applies classical overlap check instead to include > all the scenarios. > > Related to

Re: [Xen-devel] [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section

Hello, On 21/06/16 16:21, Andrew Cooper wrote: On 20/06/16 15:04, Daniel De Graaf wrote: Since FLASK is the only implementation of XSM hooks in Xen, using an iterated initcall dispatch for setup is overly complex. Change this to a direct function call to a globally visible function; if

Re: [Xen-devel] [PATCH v2 00/17] XSM/FLASK updates for 4.8

On 20/06/16 15:04, Daniel De Graaf wrote: > Changes from v1: > - Change c->context and c->sid from arrays to fields when shrinking > - Keep struct xen_flask_userlist in headers, but guard it with #ifs > - Split off Kconfig changes into their own patches > - Add patch 16 (AVC_STATS in Kconfig)

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

Juergen Gross writes ("Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging"): > Huh? Excerpt from `man logrotate`: > > Each log file may be handled daily, weekly, monthly, or when it grows > too large. > > So why is logrotate not suitable? logrotate runs "off-path", ie it

Re: [Xen-devel] [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr

On Jun 21, 2016 01:20, "Jan Beulich" wrote: > > >>> On 21.06.16 at 09:08, wrote: > > On 6/17/2016 11:25 AM, Corneliu ZUZU wrote: > >> On 6/16/2016 6:16 PM, Jan Beulich wrote: > >> On 16.06.16 at 16:12, wrote: > Prepare

Re: [Xen-devel] [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section

On 20/06/16 15:04, Daniel De Graaf wrote: > Since FLASK is the only implementation of XSM hooks in Xen, using an > iterated initcall dispatch for setup is overly complex. Change this to > a direct function call to a globally visible function; if additional XSM > hooks are added in the future, a

Re: [Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

On 21/06/16 15:17, Boris Ostrovsky wrote: > This will match how PMU errors are reported at check_hw_exists()'s > msr_fail label, which is reached when VPMU initialzation fails. Applied to for-linus-4.8, thanks. David ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 6/8] arm: vgic: Split vgic_domain_init() functionality into two functions

Hi Julien, On 06/21/2016 09:48 AM, Julien Grall wrote: On 21/06/16 15:36, Shanker Donthineni wrote: On 06/21/2016 05:49 AM, Julien Grall wrote: Hello Shanker, On 19/06/16 00:45, Shanker Donthineni wrote: Split code that installs mmio handlers for GICD and Re-distributor regions to a new

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"): > Here is what we have gathered so far: ... > We can, however, just make recommendation that system administrators can > easily set up and call it a day. There are suggestions that we can > recommend conserver or

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

On 21/06/16 16:46, Wei Liu wrote: > Here is what we have gathered so far: > > 1. Virtlogd is not the right answer to XSA-180 because it is inherently >designed to work within libvirt. > 2. Syslog is not suitable because it doesn't provide a fd for QEMU to >write to. > 3. Logrotate is not

Re: [Xen-devel] [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED

On Jun 21, 2016 05:26, "Corneliu ZUZU" wrote: > > On 6/16/2016 7:11 PM, Tamas K Lengyel wrote: >> >> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU wrote: >>> >>> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1) until the >>>

[Xen-devel] [xen-4.6-testing test] 96031: tolerable FAIL - PUSHED

flight 96031 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96031/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95849

Re: [Xen-devel] [PATCH] xen/pciback: Update data filter intersection logic.

On Tue, Jun 21, 2016 at 5:23 AM, Jan Beulich wrote: > >>> On 21.06.16 at 11:04, wrote: > On 20.06.16 at 18:23, wrote: > >> Here is printouts with applying the new logic > >> > >> [ 382.13] xen-pciback: :06:00.0: write

Re: [Xen-devel] [PATCH v4] xen: add steal_clock support on x86

On 20/05/16 08:26, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. >

Re: [Xen-devel] [PATCH 6/8] arm: vgic: Split vgic_domain_init() functionality into two functions

On 21/06/16 15:36, Shanker Donthineni wrote: On 06/21/2016 05:49 AM, Julien Grall wrote: Hello Shanker, On 19/06/16 00:45, Shanker Donthineni wrote: Split code that installs mmio handlers for GICD and Re-distributor regions to a new function. The intension of this separation is to defer

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

Here is what we have gathered so far: 1. Virtlogd is not the right answer to XSA-180 because it is inherently designed to work within libvirt. 2. Syslog is not suitable because it doesn't provide a fd for QEMU to write to. 3. Logrotate is not suitable because it only rotates periodically.

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

On 21/06/16 15:16, Shanker Donthineni wrote: On 06/21/2016 08:50 AM, Julien Grall wrote: On 21/06/16 14:37, Shanker Donthineni wrote: On 06/21/2016 04:28 AM, Julien Grall wrote: On 19/06/16 00:45, Shanker Donthineni wrote: The current driver doesn't support parsing Redistributor entries

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 21/06/16 10:47, Jan Beulich wrote: > And then - didn't we mean to disable that part of XenGT during > migration, i.e. temporarily accept the higher performance > overhead without the p2m_ioreq_server entries? In which case > flipping everything back to p2m_ram_rw after

[Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

Current overlap check is evaluating to false a case where a filter field is fully contained (proper subset) of a r/w request. This change applies classical overlap check instead to include all the scenarios. Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html Cc: Jan

Re: [Xen-devel] [PATCH 6/8] arm: vgic: Split vgic_domain_init() functionality into two functions

On 06/21/2016 05:49 AM, Julien Grall wrote: Hello Shanker, On 19/06/16 00:45, Shanker Donthineni wrote: Split code that installs mmio handlers for GICD and Re-distributor regions to a new function. The intension of this separation is to defer steps that registers vgic_v2/v3 mmio handlers.

Re: [Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

On 21/06/16 16:17, Boris Ostrovsky wrote: > This will match how PMU errors are reported at check_hw_exists()'s > msr_fail label, which is reached when VPMU initialzation fails. > > Signed-off-by: Boris Ostrovsky Acked-by: Juergen Gross > --- >

[Xen-devel] [PATCH 0/3] libxl: add framework for device types

Instead of duplicate coding for each device type (vtpms, usbctrls, ...) especially on domain creation introduce a framework for that purpose. I especially found it annoying that e.g. the vtpm callback issued the error message for a failed attach of nic devices. Juergen Gross (3): libxl: add

[Xen-devel] [PATCH 1/3] libxl: add framework for device types

Instead of duplicate coding for each device type (vtpms, usbctrls, ...) especially on domain creation introduce a framework for that purpose. Signed-off-by: Juergen Gross --- tools/libxl/libxl.c | 12 tools/libxl/libxl_create.c | 163

[Xen-devel] [PATCH 3/3] libxl: refactor domcreate_attach_dtdev() to use device type framework

Signed-off-by: Juergen Gross --- tools/libxl/libxl_create.c | 72 ++ 1 file changed, 35 insertions(+), 37 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index c4e85f0..e93b880 100644 ---

[Xen-devel] [PATCH 2/3] libxl: refactor domcreate_attach_pci() to use device type framework

Signed-off-by: Juergen Gross --- tools/libxl/libxl_create.c | 54 ++-- tools/libxl/libxl_internal.h | 1 + tools/libxl/libxl_pci.c | 36 + 3 files changed, 44 insertions(+), 47 deletions(-) diff --git

Re: [Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

On Tue, Jun 21, 2016 at 10:17:33AM -0400, Boris Ostrovsky wrote: > This will match how PMU errors are reported at check_hw_exists()'s > msr_fail label, which is reached when VPMU initialzation fails. > > Signed-off-by: Boris Ostrovsky Reviewed-by: Konrad Rzeszutek

[Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

This will match how PMU errors are reported at check_hw_exists()'s msr_fail label, which is reached when VPMU initialzation fails. Signed-off-by: Boris Ostrovsky --- arch/x86/xen/pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

On 06/21/2016 08:50 AM, Julien Grall wrote: On 21/06/16 14:37, Shanker Donthineni wrote: On 06/21/2016 04:28 AM, Julien Grall wrote: On 19/06/16 00:45, Shanker Donthineni wrote: The current driver doesn't support parsing Redistributor entries that are described in the MADT GICC table. Not

Re: [Xen-devel] [PATCH 2/8] arm/gic-v3: Fold GICR subtable parsing into a new function

On 06/21/2016 05:17 AM, Julien Grall wrote: Hello Shanker, On 19/06/16 00:45, Shanker Donthineni wrote: Add a new function for parsing GICR subtable and move the code that is specific to GICR table to new function without changing the function gicv3_acpi_init() behavior. Signed-off-by:

Re: [Xen-devel] [PATCH 3/8] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

On 06/21/2016 05:16 AM, Julien Grall wrote: Hello Shanker, On 19/06/16 00:45, Shanker Donthineni wrote: The redistributor address can be specified either as part of GICC or GICR subtable depending on the power domain. The current driver doesn't support parsing redistributor entry that is

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

On 21/06/16 14:37, Shanker Donthineni wrote: On 06/21/2016 04:28 AM, Julien Grall wrote: On 19/06/16 00:45, Shanker Donthineni wrote: The current driver doesn't support parsing Redistributor entries that are described in the MADT GICC table. Not all the GIC implementors places the

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

On 06/21/2016 04:28 AM, Julien Grall wrote: Hello Shanker, On 19/06/16 00:45, Shanker Donthineni wrote: The current driver doesn't support parsing Redistributor entries that are described in the MADT GICC table. Not all the GIC implementors places the Redistributor regions in the always-on

[Xen-devel] [xen-unstable-smoke test] 96055: tolerable all pass - PUSHED

flight 96055 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/96055/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

[Xen-devel] [libvirt test] 96038: tolerable FAIL - PUSHED

flight 96038 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/96038/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12

Re: [Xen-devel] [PATCH v9 1/3] vt-d: fix the IOMMU flush issue

>>> On 17.06.16 at 05:37, wrote: > @@ -546,17 +550,37 @@ static int __must_check iommu_flush_all(void) > struct acpi_drhd_unit *drhd; > struct iommu *iommu; > int flush_dev_iotlb; > +int rc = 0; > > flush_all_cache(); > for_each_drhd_unit ( drhd )

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

On Tue, Jun 21, 2016 at 4:01 PM, Dirk Behme wrote: > Hello Oleksandr, > > > On 21.06.2016 14:54, Oleksandr Tyshchenko wrote: >> >> On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall >> wrote: >>> >>> >>> >>> On 21/06/16 11:16, Oleksandr Tyshchenko wrote:

[Xen-devel] [PATCH v3 5/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

The correct acronym for a guest physical frame is gfn. Also use the typesafe gfn to ensure that a guest frame is effectively used. Signed-off-by: Julien Grall --- Changes in v2: - Remove extra pair of brackets. --- xen/arch/arm/domain.c | 4 ++--

[Xen-devel] [PATCH v3 2/8] xen/mm: Introduce a bunch of helpers for the typesafes mfn and gfn

Those helpers will be useful to do common operations without having to unbox/box manually the GFNs/MFNs. Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Cc: Jan Beulich Cc: Andrew Cooper Cc:

[Xen-devel] [PATCH v3 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe

The correct acronym for a guest physical frame is gfn. Also use the recently introduced typesafe gfn/mfn to avoid mixing the two different kind of frame. Signed-off-by: Julien Grall Acked-by: Jan Beulich --- Cc: Stefano Stabellini

[Xen-devel] [PATCH v3 8/8] xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn

p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename the variable to *gfn* and use typesafe to avoid possible misusage. Note that the type of the parameters 'start' and 'end' is changed from xen_pfn_t (aka uint64_t) to gfn_t (aka unsigned long). This means that a truncation will

[Xen-devel] [PATCH v3 3/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers

Also rename some variables to gfn or mfn when it does not require much rework. Finally replace %hu with %d when printing the domain id in guest_physmap_add_entry (arch/x86/mm/p2m.c). Signed-off-by: Julien Grall Acked-by: Jan Beulich --- Cc: Stefano

[Xen-devel] [PATCH v3 0/8] xen/arm: Use the typesafes gfn and mfn

Hello all, Some of the ARM functions are mixing gfn vs mfn and even physical vs frame. To avoid more confusion, this patch series makes use of the terminology described in xen/include/xen/mm.h and the associated typesafe. I pushed a branch with this series applied on xenbits:

[Xen-devel] [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

The prototype and the declaration of p2m_lookup disagree on how the function should be used. One expect a frame number whilst the other an address. Thankfully, everyone is using with an address today. However, most of the callers have to convert a guest frame to an address. Modify the interface

[Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one

The x86 version of the function xenmem_add_to_physmap_one contains variable name gpfn and gfn which make the code very confusing. I have left unchanged for now. Also, rename gpfn to gfn in the ARM version as the latter is the correct acronym for a guest physical frame. Finally, remove the

[Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

to avoid mixing machine frame with guest frame. Signed-off-by: Julien Grall Acked-by: Jan Beulich --- Cc: Stefano Stabellini Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

On Tue, Jun 21, 2016 at 4:07 PM, Julien Grall wrote: > > > On 21/06/16 13:54, Oleksandr Tyshchenko wrote: >> >> On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall >> wrote: On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

On 21/06/16 13:54, Oleksandr Tyshchenko wrote: On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall wrote: On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme wrote: I have some doubt that the current code is valid. The clock frequency is hardcoded (see

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

Hello Oleksandr, On 21.06.2016 14:54, Oleksandr Tyshchenko wrote: On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall wrote: On 21/06/16 11:16, Oleksandr Tyshchenko wrote: Hi, Dirk. Hello Oleksandr, Hello Julien. On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall wrote: > > > On 21/06/16 11:16, Oleksandr Tyshchenko wrote: >> >> Hi, Dirk. > > > Hello Oleksandr, Hello Julien. > > >> On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme >> wrote: >>> >>> In scif_uart_init()

Re: [Xen-devel] [PATCH 10/11] hvmctl: convert HVMOP_*ioreq_server*

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 June 2016 13:58 > To: xen-devel > Cc: Andrew Cooper; Paul Durrant; Wei Liu; George Dunlap; Ian Jackson; > Stefano Stabellini; dgde...@tycho.nsa.gov; Tim (Xen.org) > Subject: [PATCH 10/11] hvmctl: convert

Re: [Xen-devel] [PATCH 3/3] xen/arm: drivers: scif: Add clock auto detection

On 21/06/16 13:30, Dirk Behme wrote: diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c index bc157fe..678f46b 100644 --- a/xen/drivers/char/scif-uart.c +++ b/xen/drivers/char/scif-uart.c @@ -107,8 +107,19 @@ static void __init scif_uart_init_preirq(struct serial_port

Re: [Xen-devel] [PATCH 3/3] xen/arm: drivers: scif: Add clock auto detection

Hi Julien, On 21.06.2016 14:20, Julien Grall wrote: Hello Dirk, On 21/06/16 10:15, Dirk Behme wrote: Besides the 14MHz external clock, the SCIF might be clocked by an internal 66MHz clock. Detect this clock based on the SCIF_DL register being 0 (internal clock) or != 0 (external clock). Do

Re: [Xen-devel] [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more)

>>> On 21.06.16 at 14:05, wrote: > > On 06/17/2016 08:32 AM, Jan Beulich wrote: > On 16.06.16 at 22:27, wrote: I.e. my plan was, once the backwards moves are small enough, to maybe indeed compensate them by maintaining a

Re: [Xen-devel] [PATCH 3/3] xen/arm: drivers: scif: Add clock auto detection

Hello Dirk, On 21/06/16 10:15, Dirk Behme wrote: Besides the 14MHz external clock, the SCIF might be clocked by an internal 66MHz clock. Detect this clock based on the SCIF_DL register being 0 (internal clock) or != 0 (external clock). Do you have a public link to the specification?

Re: [Xen-devel] [PATCH 2/3] xen/arm: drivers: scif: Remove unused variables

Hello Dirk, On 21/06/16 10:15, Dirk Behme wrote: The two struct members baud and clock_hz are in the end read only variables nowhere used for anything useful. Removing them makes the code much simpler without changing any functionality. From my understanding, this patch is removing code you

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

On 21/06/16 11:16, Oleksandr Tyshchenko wrote: Hi, Dirk. Hello Oleksandr, On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme wrote: In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error if this is different later. Detect this by an ASSERT, but remove

Re: [Xen-devel] [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more)

On 06/17/2016 08:32 AM, Jan Beulich wrote: On 16.06.16 at 22:27, wrote: >>> I.e. my plan was, once the backwards moves are small enough, to maybe >>> indeed compensate them by maintaining a global variable tracking >>> the most recently returned value. There are

  1   2   >