Re: [PATCH v1 2/3] ARM: GICv3 ITS: do not invalidate memory while sending a command

Volodymyr, On Fri, 22 Sep 2023 01:22:11 +0100, Volodymyr Babchuk wrote: > > > Hi Mark, s/k/c/ > > I am writing to you, because you are GICv3 maintainer in Linux. We are > updating ITS driver in Xen and we have a question about cache > maintenance WRT memory shared with ITS. As I can see,

Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

On Tue, 06 Sep 2022 08:27:47 +0100, Leo Yan wrote: > > On Tue, Sep 06, 2022 at 09:22:00AM +0200, Ard Biesheuvel wrote: > > [...] > > > > IIUC, you consider the general flow from architecture view, so you prefer > > > to ask Xen to implement EFI stub to comply the general flow for EFI > > >

Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

On Tue, 06 Sep 2022 16:13:25 +0100, Leo Yan wrote: > > On Tue, Sep 06, 2022 at 08:53:02AM +0100, Marc Zyngier wrote: > > [...] > > > > Okay, I think have two questions for you: > > > > > > - The first question is if we really need to reserve pers

Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

On Tue, 06 Sep 2022 08:17:14 +0100, Leo Yan wrote: > > Hi Marc, > > On Tue, Sep 06, 2022 at 07:27:17AM +0100, Marc Zyngier wrote: > > On Tue, 06 Sep 2022 03:52:37 +0100, > > Leo Yan wrote: > > > > > > On Thu, Aug 2

Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

On Tue, 06 Sep 2022 03:52:37 +0100, Leo Yan wrote: > > On Thu, Aug 25, 2022 at 10:40:41PM +0800, Leo Yan wrote: > > [...] > > > > > But here I still cannot create the concept that how GIC RD tables play > > > > roles to support the para virtualization or passthrough mode. > > > > > > I am not

Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

On Thu, 18 Aug 2022 17:24:31 +0100, Ard Biesheuvel wrote: > > On Thu, 18 Aug 2022 at 17:49, Leo Yan wrote: > > > > On Thu, Aug 18, 2022 at 11:04:48AM +0100, Julien Grall wrote: > > > > [...] > > > > > > > Seems it's broken for kdump/kexec if kernel boots with using DT? > > > > > > > > > > > > >

Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

On Thu, 18 Aug 2022 10:15:30 +0100, Leo Yan wrote: > > Hi Ard, > > On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote: > > [...] > > > > This header holds ACPI spec defined data structures. This one looks > > > to be a Linux one, and hence shouldn't be defined here. You use it > >

Re: [PATCH v3 6/8] genirq: Add and use an irq_data_update_affinity helper

On Sun, 03 Jul 2022 16:22:03 +0100, Oleksandr wrote: > > > On 01.07.22 23:00, Samuel Holland wrote: > > > Hello Samuel > > > Some architectures and irqchip drivers modify the cpumask returned by > > irq_data_get_affinity_mask, usually by copying in to it. This is > > problematic for

Re: [PATCH v3 1/8] irqchip/mips-gic: Only register IPI domain when SMP is enabled

On Tue, 05 Jul 2022 14:52:43 +0100, Serge Semin wrote: > > Hi Samuel > > On Fri, Jul 01, 2022 at 03:00:49PM -0500, Samuel Holland wrote: > > The MIPS GIC irqchip driver may be selected in a uniprocessor > > configuration, but it unconditionally registers an IPI domain. > > > > Limit the part

Re: [PATCH 23/36] arm64,smp: Remove trace_.*_rcuidle() usage

> if ((unsigned)ipinr < NR_IPI) > > - trace_ipi_exit_rcuidle(ipi_types[ipinr]); > > + trace_ipi_exit(ipi_types[ipinr]); > > } > > > > static irqreturn_t ipi_handler(int irq, void *data) Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

On Fri, 29 Apr 2022 22:45:14 +0100, "Russell King (Oracle)" wrote: > > On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote: > > Thanks Marc and Michael for the review/discussion. > > > > On 29/04/2022 15:20, Marc Zyngier wrote: > >

Re: [PATCH 02/30] ARM: kexec: Disable IRQs/FIQs also on crash CPUs shutdown path

eally!) off. > > This patch mimics the ipi_cpu_stop() interrupt disable mechanism > in the crash CPU shutdown path, hence disabling IRQs/FIQs in all > secondary CPUs in the kexec/panic path as well. > > Cc: Marc Zyngier > Cc: Russell King > Signed-off-by: Guilherme G. Pi

Re: [patch 03/10] genirq/msi: Make MSI descriptor alloc/free ready for range allocations

On Sat, 27 Nov 2021 01:24:34 +, Thomas Gleixner wrote: > > Convert the MSI descriptor related functions to ranges and fixup the call > sites. > > Signed-off-by: Thomas Gleixner > --- > drivers/base/platform-msi.c |3 ++- > include/linux/msi.h |7 --- > kernel/irq/msi.c

Re: [PATCH v4 16/17] KVM: arm64: Drop perf.c and fold its tiny bits of code into arm.c

On Thu, 11 Nov 2021 02:07:37 +, Sean Christopherson wrote: > > Call KVM's (un)register perf callbacks helpers directly from arm.c and > delete perf.c > > No functional change intended. > > Signed-off-by: Sean Christopherson Reviewed-by: Marc Zyngier M.

Re: [PATCH v4 15/17] KVM: arm64: Hide kvm_arm_pmu_available behind CONFIG_HW_PERF_EVENTS=y

key's definition > out of perf.c will allow a future commit to delete perf.c entirely. > > Signed-off-by: Sean Christopherson Reviewed-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [PATCH v2] PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV

On Tue, 19 Oct 2021 22:48:19 +0100, Josef Johansson wrote: > > From: Josef Johansson > > > PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV > > commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask > functions") introduce functions pci_msi_update_mask() and >

Re: [PATCH v3 12/16] KVM: Move x86's perf guest info callbacks to generic KVM

On Mon, 11 Oct 2021 15:46:25 +0100, Sean Christopherson wrote: > > On Mon, Oct 11, 2021, Marc Zyngier wrote: > > On Wed, 22 Sep 2021 01:05:29 +0100, Sean Christopherson > > wrote: > > > diff --git a/arch/arm64/include/asm/kvm_host.h > > > b/arch/arm6

Re: [PATCH v3 15/16] KVM: arm64: Drop perf.c and fold its tiny bits of code into arm.c / pmu.c

callbacks(); > } > > static int __init early_kvm_mode_cfg(char *arg) > diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c > deleted file mode 100644 > index 0b902e0d5b5d.. > --- a/arch/arm64/kvm/perf.c > +++ /dev/null > @@ -

Re: [PATCH v3 14/16] KVM: arm64: Convert to the generic perf callbacks

nit(void) > { > if (kvm_pmu_probe_pmuver() != 0xf && !is_protected_kvm_enabled()) > static_branch_enable(_arm_pmu_available); > > - perf_register_guest_info_callbacks(_guest_cbs); > + kvm_register_perf_callbacks(NULL); > } > > void kvm_perf_teardown(voi

Re: [PATCH v3 12/16] KVM: Move x86's perf guest info callbacks to generic KVM

kernel(struct kvm_vcpu *vcpu) > return vcpu_mode_priv(vcpu); > } > > +unsigned long kvm_arch_vcpu_get_ip(struct kvm_vcpu *vcpu) > +{ > + return *vcpu_pc(vcpu); > +} > + > /* Just ensure a guest exit from a particular CPU */ > static void exit_vm_noop(void *info) > { The above nits notwithstanding, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks

On Mon, 20 Sep 2021 14:18:30 +0100, Paolo Bonzini wrote: > > On 20/09/21 14:22, Marc Zyngier wrote: > >> I think that's only ARM, and even then it is only because of > >> limitations of the hardware which mostly apply only if VHE is not in > >> use. > >&g

Re: [PATCH v2 00/13] perf: KVM: Fix, optimize, and clean up callbacks

On Mon, 20 Sep 2021 13:05:25 +0100, Paolo Bonzini wrote: > > On 17/09/21 09:28, Peter Zijlstra wrote: > >> In theory, I like the idea of burying intel_pt inside x86 (and even in > >> Intel+VMX code for the most part), but the actual implementation is a > >> bit gross. Because of the whole "KVM

Re: [patch 09/30] ARM: smp: Use irq_desc_kstat_cpu() in show_ipi_list()

On Thu, 10 Dec 2020 19:25:45 +, Thomas Gleixner wrote: > > The irq descriptor is already there, no need to look it up again. > > Signed-off-by: Thomas Gleixner > Cc: Marc Zyngier > Cc: Russell King > Cc: linux-arm-ker...@lists.infradead.org > --- > arch/arm/

Re: [patch 10/30] arm64/smp: Use irq_desc_kstat_cpu() in arch_show_interrupts()

On Thu, 10 Dec 2020 19:25:46 +, Thomas Gleixner wrote: > > The irq descriptor is already there, no need to look it up again. > > Signed-off-by: Thomas Gleixner > Cc: Mark Rutland > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Marc Zyngier > Cc: linux-arm

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

On 2020-08-28 13:54, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote: > So the arch_setup_msi_irq/etc is not really an arch hook, but some > infrastructure to support those 4 PCI root port drivers. I happen to have a *really old* patch addressing Te

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

Hi Jason, On 2020-08-28 13:19, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote: On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote: [...] > And I can't figure out what's special about tegra, rcar, and xilinx > that makes them need it as

Re: [patch V2 43/46] genirq/msi: Provide and use msi_domain_set_default_info_flags()

On 2020-08-26 12:17, Thomas Gleixner wrote: MSI interrupts have some common flags which should be set not only for PCI/MSI interrupts. Move the PCI/MSI flag setting into a common function so it can be reused. Signed-off-by: Thomas Gleixner --- V2: New patch --- drivers/pci/msi.c |7

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

On Wed, 26 Aug 2020 20:47:38 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:57 +0100, > > Thomas Gleixner wrote: > >> /** > >> - * msi_domain_free_irqs - Free interrupts from a MSI interr

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

On Wed, 26 Aug 2020 22:19:56 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:32 +0100, > > Thomas Gleixner wrote: > >> --- > >> V2: New patch. Note, that this might break other stuff which reli

Re: [patch V2 41/46] platform-msi: Provide default irq_chip:: Ack

= irq_chip_mask_parent; > if (!chip->irq_unmask) > chip->irq_unmask = irq_chip_unmask_parent; > + if (!chip->irq_ack) > + chip->irq_ack = irq_chip_ack_parent; > if (!chip->irq_eoi) > chip->irq_eoi = irq_chip_

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

nel to support the Xilinx AXI PCIe @@ -105,7 +106,6 @@ config PCIE_XILINX_CPM bool "Xilinx Versal CPM host bridge support" depends on ARCH_ZYNQMP || COMPILE_TEST select PCI_HOST_COMMON - select PCI_MSI_ARCH_FALLBACKS help Say 'Y' here if you want kernel support for the Xilinx Versal CPM host bridge. With that fixed, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI

MSI domain. > + */ > + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI); > + One day, we'll be able to set the token at domain creation time. In the meantime, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [patch V2 23/46] irqdomain/msi: Provide DOMAIN_BUS_VMD_MSI

ch(domain->bus_token) { > + case DOMAIN_BUS_PCI_MSI: > + case DOMAIN_BUS_VMD_MSI: > + break; > + default: > return false; > + } > > if (!(info->flags & MSI_FLAG_MUST_REACTIVATE)) > return false; Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [patch V2 17/46] PCI/MSI: Rework pci_msi_domain_calc_hwirq()

On Wed, 26 Aug 2020 12:16:45 +0100, Thomas Gleixner wrote: > > From: Thomas Gleixner > > Retrieve the PCI device from the msi descriptor instead of doing so at the > call sites. > > Signed-off-by: Thomas Gleixner > Acked-by: Bjorn Helgaas Acked-by: Marc Zyngier

Re: [patch V2 19/46] x86/msi: Use generic MSI domain ops

msi_prepare); > > -void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) > -{ > - arg->desc = desc; > - arg->hwirq = pci_msi_domain_calc_hwirq(desc); > -} > -EXPORT_SYMBOL_GPL(pci_msi_set_desc); I think that at this stage, pci_msi_domain_calc_hwirq() can

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

/irq/chip.c +++ b/kernel/irq/chip.c @@ -1544,7 +1544,7 @@ int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) struct irq_data *pos = NULL; #ifdef CONFIG_IRQ_DOMAIN_HIERARCHY - for (; data; data = data->parent_data) + for (; data && !pos; data = data->parent_data) #endif if (data->chip && data->chip->irq_compose_msi_msg) pos = data; Though the for loop in a #ifdef in admittedly an acquired taste... Reviewed-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

truct irq_dom > } > > /** > + * __msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain > associated tp @dev Spurious __. > + * @domain: The domain to managing the interrupts > + * @dev: Pointer to device struct of the device for which the interrupts > + * are free > + */ > +void msi_domain_free_irqs(struct irq_domain *domain, struct device *dev) > +{ > + struct msi_domain_info *info = domain->host_data; > + struct msi_domain_ops *ops = info->ops; Same thing? > + > + return ops->domain_free_irqs(domain, dev); > +} > + > +/** > * msi_get_domain_info - Get the MSI interrupt domain info for @domain > * @domain: The interrupt domain to retrieve data from > * Otherwise looks good to me: Reviewed-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.

Re: Keystone Issue

On 2020-06-17 15:45, CodeWiz2280 wrote: On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: On 2020-06-16 19:13, CodeWiz2280 wrote: > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: >> >> On 2020-06-15 20:14, CodeWiz2280 wrote: >> >> [...] >> >> &g

Re: Keystone Issue

On 2020-06-16 19:13, CodeWiz2280 wrote: On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: On 2020-06-15 20:14, CodeWiz2280 wrote: [...] > Also, the latest linux kernel still has the X-Gene storm distributor > address as "0x7801" in the device tree, which is w

Re: Keystone Issue

On 2020-06-15 20:14, CodeWiz2280 wrote: [...] Also, the latest linux kernel still has the X-Gene storm distributor address as "0x7801" in the device tree, which is what the Xen code considers a match with the old firmware. What were the addresses for the device tree supposed to be changed

Re: Keystone Issue

On 2020-06-10 13:39, CodeWiz2280 wrote: [...] The problem is that a hack may be my only solution to getting this working on this platform. If TI says that they don't support it then i'm stuck. Just to summarize the problem, we believe that the GIC is seeing secure accesses from dom0 when

Re: Keystone Issue

On 2020-06-10 09:06, Bertrand Marquis wrote: Hi, On 9 Jun 2020, at 18:45, Marc Zyngier wrote: Hi Julien, On 2020-06-09 18:32, Julien Grall wrote: (+ Marc) On 09/06/2020 18:03, Bertrand Marquis wrote: Hi On 9 Jun 2020, at 16:47, Julien Grall wrote: On 09/06/2020 16:28, Bertrand Marquis

Re: Keystone Issue

Hi Julien, On 2020-06-09 18:32, Julien Grall wrote: (+ Marc) On 09/06/2020 18:03, Bertrand Marquis wrote: Hi On 9 Jun 2020, at 16:47, Julien Grall wrote: On 09/06/2020 16:28, Bertrand Marquis wrote: Hi, On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: There does appear to be a secondary

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

George, On 2020-04-03 11:43, George Dunlap wrote: On Apr 3, 2020, at 9:47 AM, Marc Zyngier wrote: On 2020-04-02 19:52, Julien Grall wrote: (+Marc) Thanks for looping me in. Definitely an interesting read, but also a very puzzling one. [snip] No. Low latency is a very desirable thing

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On 2020-04-02 19:52, Julien Grall wrote: (+Marc) Thanks for looping me in. Definitely an interesting read, but also a very puzzling one. Hi Stefano, On 02/04/2020 18:19, Stefano Stabellini wrote: On Wed, 1 Apr 2020, Julien Grall wrote: On 01/04/2020 01:57, Stefano Stabellini wrote: On

Re: [Xen-devel] [RFC 0/6] vDSO support for Hyper-V guest on ARM64

On 2020-01-28 05:58, Boqun Feng wrote: On Fri, Jan 24, 2020 at 10:24:44AM +, Vincenzo Frascino wrote: Hi Boqun Feng, On 24/01/2020 06:32, Boqun Feng wrote: > Hi Vincenzo, > [...] >> >> I had a look to your patches and overall, I could not understand why we can't >> use the arch_timer to

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

On Fri, 31 May 2019 10:12:03 +0100, "Raslan, KarimAllah" wrote: > > On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote: > > On 17.05.19 17:41, Sironi, Filippo wrote: > > > > > > > > > > > On 16. May 2019, at 15:50, Graf, Alexander wrote: > > > > > > > > On 14.05.19 08:16, Filippo Sironi

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 12:27, Manish Jaggi wrote: > > > On 03/27/2018 04:55 PM, Marc Zyngier wrote: >> On 27/03/18 12:15, Manish Jaggi wrote: >>> >>> On 03/27/2018 04:41 PM, Marc Zyngier wrote: >>>> On 27/03/18 12:07, Manish Jaggi wrote: >>>>> On

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 12:15, Manish Jaggi wrote: > > > On 03/27/2018 04:41 PM, Marc Zyngier wrote: >> On 27/03/18 12:07, Manish Jaggi wrote: >>> >>> On 03/27/2018 04:35 PM, Marc Zyngier wrote: >>>> On 27/03/18 11:56, Manish Jaggi wrote: >>>>> On

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 12:07, Manish Jaggi wrote: > > > On 03/27/2018 04:35 PM, Marc Zyngier wrote: >> On 27/03/18 11:56, Manish Jaggi wrote: >>> >>> On 03/27/2018 04:15 PM, Marc Zyngier wrote: >>>> On 27/03/18 11:35, Manish Jaggi wrote: >>>>> On

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 11:56, Manish Jaggi wrote: > > > On 03/27/2018 04:15 PM, Marc Zyngier wrote: >> On 27/03/18 11:35, Manish Jaggi wrote: >>> >>> On 03/27/2018 04:00 PM, Marc Zyngier wrote: >>>> On 27/03/18 10:07, Manish Jaggi wrote: >&g

Re: [Xen-devel] [PATCH v2 12/17] arm64: vgic-v3: Add misc Group-0 handlers

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported to xen from linux commit: > eab0b2dc4f6f34147e3d10da49ab8032e15dbea0 > (KVM: arm64: vgic-v3: Add misc Group-0 handlers) > > A number of Group-0 registers can be handled by the same accessors > as that of Group-1, so let's add the

Re: [Xen-devel] [PATCH v2 09/17] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported from linux to xen > commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e > (KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler) > > Add a handler for reading the guest's view of the ICV_HPPIR1_EL1 > register. This is a simple parsing of the

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 11:35, Manish Jaggi wrote: > > > On 03/27/2018 04:00 PM, Marc Zyngier wrote: >> On 27/03/18 10:07, Manish Jaggi wrote: >>> This patch is ported to xen from linux commit >>> d70c7b31a60f2458f35c226131f2a01a7a98b6cf >>> KVM: arm64: vgi

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported to xen from linux commit > d70c7b31a60f2458f35c226131f2a01a7a98b6cf > KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler > > Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1 > register, which is located in the

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

On 27/03/18 11:10, Manish Jaggi wrote: > > > On 03/27/2018 03:31 PM, Marc Zyngier wrote: >> On 27/03/18 10:07, Manish Jaggi wrote: >>> The errata will require to emulate the GIC virtual CPU interface in Xen. >>> Because the hypervisor will update its in

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

On 27/03/18 10:07, Manish Jaggi wrote: > This patch is ported to xen from linux commit > b6f49035b4bf6e2709f2a5fed3107f5438c1fd02 > KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler > > Add a handler for writing the guest's view of the ICC_EOIR1_EL1 > register. This involves dropping the priority of

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

On 27/03/18 10:07, Manish Jaggi wrote: > The errata will require to emulate the GIC virtual CPU interface in Xen. > Because the hypervisor will update its internal state of the vGIC, we want > to avoid messing up with it. So the errata is handled separately from the > rest of the hypervisor. > >

Re: [Xen-devel] [PATCH v1 06/15] arm64: Add accessors for the ICH_APxRn_EL2 registers

On 26/03/18 14:19, Manish Jaggi wrote: > Hi Marc, > > I have a query on this patch. The original patch was using these > functions so it was ok to make them static. > But this patch is not touching the xen vgic code similar to what your > patch did. > > Will it be ok to merge this patch with

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

On 26/03/18 05:43, Manish Jaggi wrote: > > > On 03/23/2018 12:28 PM, Julien Grall wrote: >> (Sorry for the formatting) >> >> On 23 Mar 2018 14:46, "Manish Jaggi" > > wrote: >> >> >> >> On 03/21/2018 03:26 PM, Julien Grall wrote:

Re: [Xen-devel] [PATCH 00/12] arm64: Mediate access to GICv3 sysregs at EL2

Manish, On 12/03/18 12:42, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > This patchset is a Xen port of Marc's patchset. > arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1] > > The current RFC patchset is a subset of [1], as it handleing only Group1

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 07/12/17 18:06, George Dunlap wrote: > On 12/07/2017 04:58 PM, Marc Zyngier wrote: >> On 07/12/17 16:44, George Dunlap wrote: >>> On 12/07/2017 04:04 PM, Julien Grall wrote: >>>> Hi Jan, >>>> >>>> On 07/12/17 15:45, Jan Beulich wrote: >&

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 07/12/17 13:52, Julien Grall wrote: > (+ Marc) > > Hi, > > @Marc: My Arm cache knowledge is somewhat limited. Feel free to correct > me if I am wrong. > > Before answering to the rest of the e-mail, let me reinforce what I said > in my first e-mail. Set/Way are very complex to emulate and