Re: [Xen-devel] Ping: [PATCH v2 0/3] XSA-248...251 follow-up

>>> On 08.02.18 at 13:34, wrote: > On 02/07/2018 03:27 PM, Jan Beulich wrote: > On 20.12.17 at 10:37, wrote: >>> The parts of this series aren't really dependent upon one another, >>> they belong together solely because of their origin. >>> >>> 1: x86/shadow: widen

[Xen-devel] [seabios test] 119025: trouble: blocked/broken/fail/pass

flight 119025 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119025/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvopsbroken build-amd64-pvops

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

> From: Paul Durrant > Sent: Monday, February 12, 2018 6:47 PM > > This patch adds iommu_ops to allow a domain with control_iommu > privilege > to map and unmap pages from any guest over which it has mapping > privilege > in the IOMMU. > These operations implicitly disable IOTLB flushing so that

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

> From: Paul Durrant > Sent: Monday, February 12, 2018 6:47 PM > > Certain areas of memory, such as RMRRs, must be mapped 1:1 > (i.e. BFN == MFN) through the IOMMU. > > This patch adds an iommu_op to allow these ranges to be queried. > > Signed-off-by: Paul Durrant >

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

> From: Paul Durrant > Sent: Monday, February 12, 2018 6:47 PM > > This patch introduces the boilerplate for a new hypercall to allow a > domain to control IOMMU mappings for its own pages. > Whilst there is duplication of code between the native and compat entry > points which appears ripe for

Re: [Xen-devel] [PATCH 0/7] paravirtual IOMMU interface

> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Monday, February 12, 2018 6:47 PM > > The idea of a paravirtual IOMMU interface was last discussed on xen-devel > more than two years ago and narrowed down on a draft specification [1]. > There was also an RFC patch series posted with

[Xen-devel] [PATCH v2] pvcalls-front improvements

Hi all, this small series introduces a per socket refcount to increase the efficiency on socket release operations, and makes releasing passive sockets safe. Cheers, Stefano Changes in v2: - add acked-by - fix check in pvcalls_enter_soc - fix code style - nicer checks in pvcalls_front_release

[Xen-devel] [PATCH v2 1/2] pvcalls-front: introduce a per sock_mapping refcount

Introduce a per sock_mapping refcount, in addition to the existing global refcount. Thanks to the sock_mapping refcount, we can safely wait for it to be 1 in pvcalls_front_release before freeing an active socket, instead of waiting for the global refcount to be 1. Signed-off-by: Stefano

Re: [Xen-devel] [PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

On Mon, 12 Feb 2018, Juergen Gross wrote: > On 05/02/18 23:51, Stefano Stabellini wrote: > > Passive sockets can have ongoing operations on them, specifically, we > > have two wait_event_interruptable calls in pvcalls_front_accept. > > > > Add two wake_up calls in pvcalls_front_release, then wait

Re: [Xen-devel] [PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

On Mon, 12 Feb 2018, Juergen Gross wrote: > On 05/02/18 23:51, Stefano Stabellini wrote: > > Introduce a per sock_mapping refcount, in addition to the existing > > global refcount. Thanks to the sock_mapping refcount, we can safely wait > > for it to be 1 in pvcalls_front_release before freeing an

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

On Fri, 9 Feb 2018, Christian Lindig wrote: Sorry, I can’t make a promise because of my other obligations. I do wonder, though: this patch did not come out of nowhere but supposedly was working - what is different here? The patch was from Fedora and is broken there too! It fixes the build

[Xen-devel] [qemu-mainline test] 119000: regressions - FAIL

flight 119000 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119000/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 118942 Tests which

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

On 12/02/2018 23:16, Mirela Simonovic wrote: Hi Julien, Hi, On 02/12/2018 10:41 PM, Julien Grall wrote: On 12/02/2018 20:12, Mirela Simonovic wrote: Hi Julien, Hi Mirela, Thank you for the review. I've done pretty much the same work in parallel, but there are few additional minor

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

Hi Julien, On 02/12/2018 10:41 PM, Julien Grall wrote: On 12/02/2018 20:12, Mirela Simonovic wrote: Hi Julien, Hi Mirela, Thank you for the review. I've done pretty much the same work in parallel, but there are few additional minor changes I've made. Briefly, the difference is in

[Xen-devel] [linux-next test] 118987: regressions - FAIL

flight 118987 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/118987/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-examine 8 reboot fail REGR. vs. 118893 test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

On 12/02/2018 20:12, Mirela Simonovic wrote: Hi Julien, Hi Mirela, Thank you for the review. I've done pretty much the same work in parallel, but there are few additional minor changes I've made. Briefly, the difference is in return values that some already implemented functions should

[Xen-devel] [seabios test] 118982: regressions - trouble: broken/fail/pass

flight 118982 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118982/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd broken

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

Hi Julien, I've done pretty much the same work in parallel, but there are few additional minor changes I've made. Briefly, the difference is in return values that some already implemented functions should return starting from v1.0 (and even v0.2 errata). Please let me know whether you omitted

[Xen-devel] [xtf test] 119006: all pass - PUSHED

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

Re: [Xen-devel] Xen ARM community call Tuesday 13th February 5PM UTC

Hi all, Quick reminder, the meeting will be tomorrow (Tuesday 13th February) at 5PM UTC. We will use uberconference for the meeting: Join the call: https://www.uberconference.com/stefano-stabellini Optional dial in number: 669-999-0613 No PIN needed Cheers, On 06/02/18 10:11, Julien

Re: [Xen-devel] [RFC PATCH 22/49] ARM: new VGIC: Implement virtual IRQ injection

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: Provide a vgic_queue_irq_unlock() function which decides whether a given IRQ needs to be queued to a VCPU's ap_list. This should be called whenever an IRQ becomes pending or enabled, either as a result of a hardware IRQ injection, from devices

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

On 12/02/18 18:41, Roger Pau Monné wrote: > On Mon, Feb 12, 2018 at 03:04:21PM +, Andrew Cooper wrote: >> On 12/02/18 14:39, Wei Liu wrote: >>> On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote: .macro ALTERNATIVE oldinstr, newinstr, feature .L\@_orig_s:

Re: [Xen-devel] RTDS with extra time issue

Dario, On 12.02.18 12:20, Andrii Anisov wrote: Actually as per Meng's explanation and calculations the problem was on my side - wrong DomR task/VCPU parameters. I was running the system with dummy loads and values received from CARTS and all seems to be ok (no deadline misses occured). Well,

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

On Mon, Feb 12, 2018 at 03:04:21PM +, Andrew Cooper wrote: > On 12/02/18 14:39, Wei Liu wrote: > > On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote: > >> .macro ALTERNATIVE oldinstr, newinstr, feature > >> .L\@_orig_s: > >> \oldinstr > >> .L\@_orig_e: > >> + .skip

Re: [Xen-devel] [RFC PATCH 17/49] ARM: timer: Handle level triggered IRQs correctly

Hi, On 12/02/18 15:19, Julien Grall wrote: > Hi Andre, > > On 09/02/18 14:39, Andre Przywara wrote: >> The ARM Generic Timer uses a level-sensitive interrupt semantic. We >> easily catch when the line goes high, as this triggers the hardware IRQ. >> However we have to sync the state of the

Re: [Xen-devel] [PATCH 6/7] x86/alt: Drop explicit padding of origin sites

On Mon, Feb 12, 2018 at 11:23:06AM +, Andrew Cooper wrote: > Now that the alternatives infrastructure can calculate the required padding > automatically, there is no need to hard code it. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote: > The correct amount of padding in an origin patch site can be calculated > automatically, based on the relative lengths of the replacements. > > This requires a bit of trickery to calculate correctly, especially in the >

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

On 12/02/18 17:26, Roger Pau Monné wrote: > On Mon, Feb 12, 2018 at 11:23:03AM +, Andrew Cooper wrote: >> * On the C side, switch to using local lables rather than hardcoded numbers. > ^ labels >> * Rename parameters and lables to be consistent with

Re: [Xen-devel] [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ

Hi, On 12/02/18 13:55, Julien Grall wrote: > Hi Andre, > > On 09/02/18 14:39, Andre Przywara wrote: >> When playing around with hardware mapped, level triggered virtual IRQs, >> there is the need to explicitly set the active state of an interrupt at >> some point in time. >> To prepare the GIC

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

On 12/02/18 17:18, Wei Liu wrote: > On Mon, Feb 12, 2018 at 04:52:21PM +, Roger Pau Monné wrote: >> On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote: >>> * Rename some fields for consistency and clarity, and use standard types. >>> * Don't opencode the use of

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote: > With future changes, altinstruction_entry is going to become more complicated > to use. Furthermore, there are already ALTERNATIVE* macros which can be used > to avoid opencoding the creation of replacement information. > > For

Re: [Xen-devel] [RFC PATCH 21/49] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The new VGIC implementation centers around a struct vgic_irq instance per virtual IRQ. Provide a function to retrieve the right instance for a given IRQ number and (in case of private interrupts) the right VCPU. This also includes the

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

On Mon, Feb 12, 2018 at 11:23:03AM +, Andrew Cooper wrote: > * On the C side, switch to using local lables rather than hardcoded numbers. ^ labels > * Rename parameters and lables to be consistent with alt_instr names, and

Re: [Xen-devel] [PATCH v2 11/15] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 12/02/18 17:20, Volodymyr Babchuk wrote: Julien, Hi, On 12.02.18 19:12, Julien Grall wrote: On 12/02/18 16:55, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 08.02.18 21:21, Julien Grall wrote: Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Re: [Xen-devel] [PATCH v2 11/15] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Julien, On 12.02.18 19:12, Julien Grall wrote: On 12/02/18 16:55, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 08.02.18 21:21, Julien Grall wrote: Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. Signed-off-by: Julien Grall ---

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

On Mon, Feb 12, 2018 at 04:52:21PM +, Roger Pau Monné wrote: > On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote: > > * Rename some fields for consistency and clarity, and use standard types. > > * Don't opencode the use of ALT_{ORIG,REPL}_PTR(). > > > > No functional change. >

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote: > * Rename some fields for consistency and clarity, and use standard types. > * Don't opencode the use of ALT_{ORIG,REPL}_PTR(). > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by:

Re: [Xen-devel] [RFC PATCH 20/49] ARM: new VGIC: Add data structure definitions

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: Add a new header file for the new and improved GIC implementation. The big change is that we now have a struct vgic_irq per IRQ instead of spreading all the information over various bitmaps in the ranks. We include this new header

[Xen-devel] [linux-linus test] 118968: regressions - FAIL

flight 118968 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

On Mon, Feb 12, 2018 at 8:54 AM, Andrew Cooper wrote: > On 12/02/18 15:08, Alexandru Isaila wrote: >> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) >> break; >> >> case VMEXIT_EXCEPTION_BP: >> -if (

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

On 12/02/18 15:56, Roger Pau Monné wrote: > On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote: >> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to >> calculating extra padding length, and we have no need for the complexity. >> >> Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote: > ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to > calculating extra padding length, and we have no need for the complexity. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

On 12/02/18 15:08, Alexandru Isaila wrote: > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) > break; > > case VMEXIT_EXCEPTION_BP: > -if ( !v->domain->debugger_attached ) > -goto unexpected_exit_type; > -/* AMD Vol2, 15.11:

Re: [Xen-devel] [PATCH v4 21/28] vvtd: update hvm_gmsi_info when binding guest msi with pirq or

On Fri, Nov 17, 2017 at 02:22:28PM +0800, Chao Gao wrote: > ... handlding guest's invalidation request. > > To support pirq migration optimization and using VT-d posted interrupt to > inject msi from assigned devices, each time guest programs msi information > (affinity, vector), the struct

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

On 12/02/18 15:17, Zhongze Liu wrote: Hi Julien, Hi, 2018-02-12 23:09 GMT+08:00 Julien Grall : Hi, On 12/02/18 14:52, Zhongze Liu wrote: 2018-02-08 0:54 GMT+08:00 Julien Grall : On 07/02/18 16:27, Zhongze Liu wrote: It seems that I

Re: [Xen-devel] [RFC PATCH 17/49] ARM: timer: Handle level triggered IRQs correctly

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The ARM Generic Timer uses a level-sensitive interrupt semantic. We easily catch when the line goes high, as this triggers the hardware IRQ. However we have to sync the state of the interrupt condition at certain points to catch when the line

Re: [Xen-devel] [PATCH v4 20/28] xen/pt: when binding guest msi, accept the whole msi message

On Fri, Nov 17, 2017 at 02:22:27PM +0800, Chao Gao wrote: > ... rather than a filtered one. Previously, some fields (reserved or > unalterable) are filtered by QEMU. These fields are useless for the > legacy interrupt format (i.e. non remappable format). However, these > fields are meaningful to

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

On 12/02/18 15:08, Alexandru Isaila wrote: > No monitor features are available on AMD and all > capabilities are passed only to the Intel processor architecture. > This means that the arch_monitor_get_capabilities returns > capabilities = 0. > > This patch is separating out features which are

[Xen-devel] [PATCH v3 3/4] hvm/svm: Enable MSR events

At this moment there is no function to enable msr interception on svm. This patch implements this function and moves the mov to msr monitor event form the Intel arch side to the common capabilities. Signed-off-by: Alexandru Isaila Acked-by: Tamas K Lengyel

[Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

No monitor features are available on AMD and all capabilities are passed only to the Intel processor architecture. This means that the arch_monitor_get_capabilities returns capabilities = 0. This patch is separating out features which are implemented on both systems from those implemented only on

[Xen-devel] [PATCH v3 4/4] hvm/svm: Enable CR events

The CR_INTERCEPT_CR3_WRITE intercept is out of the vmcb->_cr_intercepts so the AMD arch can't intercept CR events. This patch implements the CR intercept by adding the flag on a write_ctrlreg event. The monitor write ctrlreg event is moved from the Intel side to the common capabilities side. We

[Xen-devel] [PATCH v3 0/4] hvm/svm: Enable vm events for SVM

Hi all, This series provides a skeleton for enabling vm_events on SVM. For the first step, the MSR, CR, Breakpoint and GuestRequest have been tested and added to the capabilities list. Cheers, Alexandru Isaila ___ Xen-devel mailing list

[Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

This commit implements the breakpoint events for svm. At the moment, the Breakpoint vmexit is not forwarded to the monitor layer. This patch adds the hvm_monitor_debug call to the VMEXIT_EXCEPTION_BP. Also, the Software Breakpoint cap is moved from the Intel arch to the common part of the code.

Re: [Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

Hi Wei and Julien, 2018-02-07 1:47 GMT+08:00 Wei Liu : > On Tue, Feb 06, 2018 at 05:30:50PM +, Julien Grall wrote: >> >> >> On 02/06/2018 03:59 PM, Zhongze Liu wrote: >> > Hi Julien, >> >> Hi, >> >> >> > 2018-02-06 21:07 GMT+08:00 Julien Grall : >> >

Re: [Xen-devel] [PATCH v2 09/15] xen/arm: psci: Detect SMCCC version

On 12/02/18 14:43, Volodymyr Babchuk wrote: Hi Julien, On 09.02.18 19:09, Julien Grall wrote: On 02/09/2018 05:04 PM, Volodymyr Babchuk wrote: Julien, On 08.02.18 21:21, Julien Grall wrote: PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed via PSCI_FEATURES. If the

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

On 12/02/18 14:39, Wei Liu wrote: > On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote: >> The correct amount of padding in an origin patch site can be calculated >> automatically, based on the relative lengths of the replacements. >> >> This requires a bit of trickery to calculate

Re: [Xen-devel] [PATCH v4 19/28] x86/vioapic: extend vioapic_get_vector() to support remapping format RTE

On Fri, Nov 17, 2017 at 02:22:26PM +0800, Chao Gao wrote: > When IOAPIC RTE is in remapping format, it doesn't contain the vector of > interrupt. For this case, the RTE contains an index of interrupt remapping > table where the vector of interrupt is stored. This patchs gets the vector > through a

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

On Fri, Feb 09, 2018 at 09:20:33AM +, Christian Lindig wrote: > > > > On 8. Feb 2018, at 18:24, Wei Liu wrote: > > > > Christian, do you have any idea when you can look into fixing the > > safe-string patch? > > Sorry, I can’t make a promise because of my other

Re: [Xen-devel] [PATCH v4 18/28] x86/vioapic: Hook interrupt delivery of vIOAPIC

On Fri, Nov 17, 2017 at 02:22:25PM +0800, Chao Gao wrote: > When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping > format. If that, generate an irq_remapping_request and call the common "If that's the case, ..." > VIOMMU abstraction's callback to handle this interrupt

Re: [Xen-devel] RTDS with extra time issue

On Mon, Feb 12, 2018 at 6:08 AM, Andrii Anisov wrote: > > Dario, Meng, > > > On 12.02.18 12:17, Dario Faggioli wrote: >> >> Well, I'll let Andrii reply, but honestly, I don't think it is. >> >> See, for instance, the fact that DomR has only 1 vCPU, so I find it >> unlikely

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

Hi Julien an Wei, 2018-02-08 0:54 GMT+08:00 Julien Grall : > On 07/02/18 16:27, Zhongze Liu wrote: >> >> Hi Wei and Julien, > > > Hi, > > >> 2018-02-07 2:06 GMT+08:00 Wei Liu : >>> >>> On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote: >

Re: [Xen-devel] libx[lc]: Improve error reporting for invalid kernel images

On Thu, Feb 08, 2018 at 10:49:07PM +0100, Simon Gaiser wrote: > Simon Gaiser (3): > libxc: Cleanup xc_dom_parse_elf_kernel()'s return value > libxl: Improve logging in libxl__build_dom() > libxc: xc_dom_parse_elf_kernel: Return error for invalid kernel images Acked-by: Wei Liu

Re: [Xen-devel] [PATCH 1/7] Port WARN_ON_ONCE() from Linux

On Thu, Feb 08, 2018 at 08:10:49PM -0700, Sameer Goel wrote: > > +#define WARN_ON_ONCE(p) \ > +({ \ > +static bool __section(".data.unlikely") __warned; \ > +int __ret_warn_once = !!(p);\ > +

Re: [Xen-devel] [PATCH v4 17/28] x86/vvtd: save and restore emulated VT-d

On Fri, Nov 17, 2017 at 02:22:24PM +0800, Chao Gao wrote: > Provide a save-restore pair to save/restore registers and non-register > status. > > Signed-off-by: Chao Gao > Signed-off-by: Lan Tianyu > --- > v3: > - use one entry to save both vvtd

Re: [Xen-devel] [PATCH 2/7] xen/bitops: Rename LOG_2 to ilog2

On Thu, Feb 08, 2018 at 08:10:50PM -0700, Sameer Goel wrote: > Changing the name of the macro from LOG_2 to ilog2.This makes the function > name > similar to its Linux counterpart. Since, this is not used in multiple places, > the code churn is minimal. > > This change helps in porting unchanged

Re: [Xen-devel] [PATCH v2 09/15] xen/arm: psci: Detect SMCCC version

Hi Julien, On 09.02.18 19:09, Julien Grall wrote: On 02/09/2018 05:04 PM, Volodymyr Babchuk wrote: Julien, On 08.02.18 21:21, Julien Grall wrote: PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

On Thu, Feb 08, 2018 at 07:21:50PM +, Julien Grall wrote: > At the moment, Xen provides virtual PSCI interface compliant with 0.1 > and 0.2. Since them, the specification has been updated and the latest > version is 1.1 (see ARM DEN 0022D). > > From an implementation point of view, only

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

On Mon, Feb 12, 2018 at 09:27:25AM +0100, Yessine Daoud wrote: > Hello, > > Thank you for your quick response. > Any hints how can I "fix" this "issue"? *Any workaround? > Honestly I have no idea why it is slow unless there is more logging available. Wei.

Re: [Xen-devel] [PATCH 7/7] x86/build: Use new .nop directive when available

On Mon, Feb 12, 2018 at 11:23:07AM +, Andrew Cooper wrote: > Newer versions of binutils are capable of emitting an exact number bytes worth > of optimised nops. Use this in preference to .skip when available. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH 6/7] x86/alt: Drop explicit padding of origin sites

On Mon, Feb 12, 2018 at 11:23:06AM +, Andrew Cooper wrote: > Now that the alternatives infrastructure can calculate the required padding > automatically, there is no need to hard code it. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote: > The correct amount of padding in an origin patch site can be calculated > automatically, based on the relative lengths of the replacements. > > This requires a bit of trickery to calculate correctly, especially in the >

Re: [Xen-devel] [PATCH v4 16/28] x86/vvtd: Add queued invalidation (QI) support

On Fri, Nov 17, 2017 at 02:22:23PM +0800, Chao Gao wrote: > Queued Invalidation Interface is an expanded invalidation interface with > extended capabilities. Hardware implementations report support for queued > invalidation interface through the Extended Capability Register. The queued >

Re: [Xen-devel] [PATCH v4 15/28] x86/vvtd: Enable Queued Invalidation through GCMD

On Fri, Nov 17, 2017 at 02:22:22PM +0800, Chao Gao wrote: > Software writes to QIE field of GCMD to enable or disable queued > invalidations. This patch emulates QIE field of GCMD. > > Signed-off-by: Chao Gao > Signed-off-by: Lan Tianyu > --- >

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

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

Re: [Xen-devel] [RFC PATCH 16/49] ARM: GIC: allow reading pending state of a hardware IRQ

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: To synchronize level triggered interrupts which are mapped into a guest, we need to update the virtual line level at certain points in time. For a hardware mapped interrupt the GIC is the only place where we can easily access this information.

Re: [Xen-devel] [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: When playing around with hardware mapped, level triggered virtual IRQs, there is the need to explicitly set the active state of an interrupt at some point in time. To prepare the GIC for that, we introduce a set_active_state() function to let

Re: [Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

On 08/02/18 00:49, Prarit Bhargava wrote: > The kernel panics on PV domains because native_smp_cpus_done() is > only called for HVM domains. > > Calculate __max_logical_packages for PV domains. > > Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate") > Signed-off-by: Prarit

Re: [Xen-devel] [PATCH v2] xenbus: track caller request id

On 02/02/18 18:42, Joao Martins wrote: > Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent > xenstore accesses") optimized xenbus concurrent accesses but in doing so > broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in > charge of xenbus message

Re: [Xen-devel] [PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

On 05/02/18 23:51, Stefano Stabellini wrote: > Passive sockets can have ongoing operations on them, specifically, we > have two wait_event_interruptable calls in pvcalls_front_accept. > > Add two wake_up calls in pvcalls_front_release, then wait for the > potential waiters to return and release

Re: [Xen-devel] [PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

On 05/02/18 23:51, Stefano Stabellini wrote: > Introduce a per sock_mapping refcount, in addition to the existing > global refcount. Thanks to the sock_mapping refcount, we can safely wait > for it to be 1 in pvcalls_front_release before freeing an active socket, > instead of waiting for the

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-xsm testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git

Re: [Xen-devel] [PATCH v4 14/28] x86/vvtd: Handle interrupt translation faults

On Fri, Nov 17, 2017 at 02:22:21PM +0800, Chao Gao wrote: > Interrupt translation faults are non-recoverable fault. When faults > are triggered, it needs to populate fault info to Fault Recording > Registers and inject msi interrupt to notify guest IOMMU driver > to deal with faults. > > This

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote: > With future changes, altinstruction_entry is going to become more complicated > to use. Furthermore, there are already ALTERNATIVE* macros which can be used > to avoid opencoding the creation of replacement information. > > For

[Xen-devel] Realloc VM's memory while running

Hi all, I am working in a project in which we try to switch domain's underlying machine memory(MFNs) for another "chunk" of the same size while the VM is running. This can be useful for example when a domain running a memory intensive load experiences performance penalties(e.g: lot of cache

Re: [Xen-devel] [PATCH] libxc: check for null size file mapping

On Mon, Feb 12, 2018 at 01:09:15PM +0100, Paul Semel wrote: > Changed the error message when trying to map a null size file. > When doing `xl create` command, we get an Invalid Kernel error > when the file size is greater than zero. For zero length files, we are > falling in the mmap error, and we

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

On 12/02/18 12:30, Wei Liu wrote: > On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote: >> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S >> index 58f652d..bd3819a 100644 >> --- a/xen/arch/x86/x86_64/entry.S >> +++ b/xen/arch/x86/x86_64/entry.S >> @@ -557,23

Re: [Xen-devel] [RFC PATCH 14/49] ARM: VGIC: extend GIC CPU interface definitions

Hi, This patch seem to modify the GICv2 CPU interface definitions. If so, please make it clear in the commit message/title. On 09/02/18 14:39, Andre Przywara wrote: The new VGIC will shortly use more bits of the GICC_CTLR register, so add the respective definitions from the manual. Also add

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote: > ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to > calculating extra padding length, and we have no need for the complexity. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

On Mon, Feb 12, 2018 at 11:23:03AM +, Andrew Cooper wrote: > * On the C side, switch to using local lables rather than hardcoded numbers. > * Rename parameters and lables to be consistent with alt_instr names, and >consistent between the the C and asm versions. > * On the asm side,

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote: > diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S > index 58f652d..bd3819a 100644 > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -557,23 +557,9 @@ handle_exception_saved: >

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote: > * Rename some fields for consistency and clarity, and use standard types. > * Don't opencode the use of ALT_{ORIG,REPL}_PTR(). And change u8 etc. > > No functional change. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [RFC PATCH 09/49] ARM: VGIC: change to level-IRQ compatible IRQ injection interface

On 12/02/18 11:59, Andre Przywara wrote: Hi, Hi Andre, On 12/02/18 11:15, Julien Grall wrote: Hi Andre, On 09/02/18 14:38, Andre Przywara wrote: diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 5f47aa84a9..2fc6e19625 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c

Re: [Xen-devel] [PATCH v4 13/28] x86/vvtd: add a helper function to decide the interrupt format

On Fri, Nov 17, 2017 at 02:22:20PM +0800, Chao Gao wrote: > Different platform may use different method to distinguish > remapping format interrupt and normal format interrupt. > > Intel uses one bit in IOAPIC RTE or MSI address register to > indicate the interrupt is remapping format. vvtd

Re: [Xen-devel] [RFC PATCH 13/49] ARM: VGIC: Add hypervisor base address to vgic_v2_setup_hw()

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The new VGIC will need to know the hypervisor base address at some point, which is private to the hardware facing part of the VGIC so far. Add a parameter to vgic_v2_setup_hw() to pass this address on, so a VGIC implementation can make use of

Re: [Xen-devel] [RFC PATCH 09/49] ARM: VGIC: change to level-IRQ compatible IRQ injection interface

Hi, On 12/02/18 11:15, Julien Grall wrote: > Hi Andre, > > On 09/02/18 14:38, Andre Przywara wrote: >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c >> index 5f47aa84a9..2fc6e19625 100644 >> --- a/xen/arch/arm/vgic.c >> +++ b/xen/arch/arm/vgic.c >> @@ -285,7 +285,7 @@ bool

Re: [Xen-devel] [RFC PATCH 12/49] ARM: VGIC: introduce gic_get_nr_lrs()

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: So far the number of list registers (LRs) a GIC implements is only needed in the hardware facing side of the VGIC code (gic-vgic.c). The new VGIC will need this information in more and multiple places, so export a function that returns the

Re: [Xen-devel] [PATCH v4 12/28] x86/vvtd: decode interrupt attribute from IRTE

On Fri, Nov 17, 2017 at 02:22:19PM +0800, Chao Gao wrote: > Without interrupt remapping, interrupt attributes can be extracted from > msi message or IOAPIC RTE. However, with interrupt remapping enabled, > the attributes are enclosed in the associated IRTE. This callback is > for cases in which

Re: [Xen-devel] [RFC PATCH 11/49] ARM: VGIC: reorder prototypes in vgic.h

Hi Andre, On 09/02/18 14:38, Andre Przywara wrote: /* - * Allocate a guest VIRQ - * - spi == 0 => allocate a PPI. It will be the same on every vCPU - * - spi == 1 => allocate an SPI + * In the moment vgic_num_irqs() just covers SPIs and the private IRQs, + * as it's mostly used for

Re: [Xen-devel] [RFC PATCH 00/49] New VGIC(-v2) implementation

Hi, On 12/02/18 11:48, Julien Grall wrote: > > > On 09/02/18 15:06, Andre Przywara wrote: >> Hi, > > Hi Andre, > >> On 09/02/18 14:38, Andre Przywara wrote: >>> tl;dr: More preparatory patches from patch 07, actual new VGIC starting >>> at patch 20. >>> = >>> >>> During

Re: [Xen-devel] [RFC PATCH 00/49] New VGIC(-v2) implementation

On 09/02/18 15:06, Andre Przywara wrote: Hi, Hi Andre, On 09/02/18 14:38, Andre Przywara wrote: tl;dr: More preparatory patches from patch 07, actual new VGIC starting at patch 20. = During development of the Dom0 ITS MSI support last year we realised that the existing GIC

  1   2   >