search for: eoi

We need to write the irq number to GICC_DIR on the physical cpu that previously received the interrupt, but currently we are doing it on the pcpu that received the maintenance interrupt. As a consequence if a vcpu is migrated to a different pcpu, the irq is going to be EOI''ed on the wrong pcpu. This covers the case where dom0 vcpu0 is running on pcpu1 for example (you can test this scenario by using xl vcpu-pin). Changes in v2: - pass virq by value to gic_irq_eoi; - EOI the interrupt without any spin locks held and with interrupt enabled. Signed-off-by:...

We need to write the irq number to GICC_DIR on the physical cpu that previously received the interrupt, but currently we are doing it on the pcpu that received the maintenance interrupt. As a consequence if a vcpu is migrated to a different pcpu, the irq is going to be EOI''ed on the wrong pcpu. This covers the case where dom0 vcpu0 is running on pcpu1 for example (you can test this scenario by using xl vcpu-pin). Changes in v3: - use an int rather than a cpumask to store the EOI cpu; - adds the eoi cpu to arch_irq_desc. Changes in v2: - pass virq by valu...

Wei, Quick question: Am I reading the code correctly, that even with per-device interrupt remap tables, that GSIs are accounted to the intremap table of the corresponding IOAPIC, presumably because the IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In that case, then we need all devices sharing the same IOAPIC must not have any vector collisions. Is that correct? -George

The behaviour of default ISRs as provided by the BIOS varies wildly between platforms. Some will simply iret, some will send EOI, some will send EOI and disable the interrupt at the PIC, some will crash the machine due to single-bit errors in the ISR address. When PXENV_UNDI_ISR_IN_START returns PXENV_UNDI_ISR_OUT_NOT_OURS, send the EOI ourselves rather than risking the unpredictable behaviour of chaining to the original IS...

...een modified to return a boolean indicating whether the irq is real or not, and in the case of a spurious vector, the error in do_IRQ() is not printed. One complication is that now, _mask_and_ack_8259A_irq() can get called whatever the ack mode is, so has been altered to work out whether it should EOI the irq or not. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> -- Changes since v1 * Modify _mask_and_ack_8259A_irq() rather than basically duplicating it diff -r 1126b3079bef -r 3cacac4d8a4d xen/arch/x86/i8259.c --- a/xen/arch/x86/i8259.c +++ b/xen/arch/x86/i8259.c @@ -85,10...

...t;rkagan at virtuozzo.com> >> CC: Denis V. Lunev <den at openvz.org> >> CC: qemu-devel at nongnu.org >> CC: virtualization at lists.linux-foundation.org > Bad news. > > The test breaks with APICv, because of the following sequence of events: > > 1) non-auto-EOI interrupt 176 is injected into IRR and ISR > > 2) The PPR register is now 176 > > 3) auto-EOI interrupt 179 is injected into IRR only, because (179 & > 0xf0) <= (PPR & 0xf0) > > 4) interrupt 176 ISR performs an EOI > > 5) at this point, because virtual interrup...

...t;rkagan at virtuozzo.com> >> CC: Denis V. Lunev <den at openvz.org> >> CC: qemu-devel at nongnu.org >> CC: virtualization at lists.linux-foundation.org > Bad news. > > The test breaks with APICv, because of the following sequence of events: > > 1) non-auto-EOI interrupt 176 is injected into IRR and ISR > > 2) The PPR register is now 176 > > 3) auto-EOI interrupt 179 is injected into IRR only, because (179 & > 0xf0) <= (PPR & 0xf0) > > 4) interrupt 176 ISR performs an EOI > > 5) at this point, because virtual interrup...

...ption of the patches from Yunhong''s mail. The basic idea including: 1) Keep vector global resource owned by xen, while split pirq into per-domain information. 2) Domain0 kernel will operate msi resource for domain0/domU, while QEMU will operate MSI resource for HVM domain. 3) Xen will do EOI for MSI interrupt. Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com <mailto:yunhong.jiang@intel.com> > There are no much changes made compared with the original patches. But there do have some issues that we need your kind comments. 1> ACK-NEW method is necessary to a...

...e io_apic.c for more details). - State machine: Whenever an interrupt occur (both for an assertion or deassertion): 1. Ack & Mask the interrupt 2. Assert/Deassert virtual line of NativeDom (Interrupt action). 3. Change pin''s polarity 4. EOI & Unmask Signed-off-by: Guy Zana <guy@neocleus.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Recently our automated testing system has caught a curious assertion while testing Xen 4.1.5 on a HaswellDT system. (XEN) Assertion ''(sp == 0) || (peoi[sp-1].vector < vector)'' failed at irq.c:1030 (XEN) ----[ Xen-4.1.5 x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff82c48016b2b4>] do_IRQ+0x514/0x750 (XEN) RFLAGS: 0000000000010093 CONTEXT: hypervisor (XEN) rax: 000000000000002f rbx: ffff830249841e8...

The following 5 patches are re-submissions of the vt-d patch. This set of patches has been tested against cs# 15080 and is now much more mature and tested against more environments than the original patch. Specifically, we have successfully tested the patch with following environements: - 32/64-bit Linux HVM guest - 32-bit Windows XP/Vista (64-bit should work but did not test) -

...2) +#define HV_SYNIC_CONTROL_ENABLE (1ULL << 0) +#define HV_SYNIC_SIMP_ENABLE (1ULL << 0) +#define HV_SYNIC_SIEFP_ENABLE (1ULL << 0) +#define HV_SYNIC_SINT_MASKED (1ULL << 16) +#define HV_SYNIC_SINT_AUTO_EOI (1ULL << 17) +#define HV_SYNIC_SINT_VECTOR_MASK (0xFF) +#define HV_SYNIC_SINT_COUNT 16 + +enum { + HV_TEST_DEV_SINT_ROUTE_CREATE = 1, + HV_TEST_DEV_SINT_ROUTE_DESTROY, + HV_TEST_DEV_SINT_ROUTE_SET_SINT +}; + +static atomic_t isr_ente...

...2) +#define HV_SYNIC_CONTROL_ENABLE (1ULL << 0) +#define HV_SYNIC_SIMP_ENABLE (1ULL << 0) +#define HV_SYNIC_SIEFP_ENABLE (1ULL << 0) +#define HV_SYNIC_SINT_MASKED (1ULL << 16) +#define HV_SYNIC_SINT_AUTO_EOI (1ULL << 17) +#define HV_SYNIC_SINT_VECTOR_MASK (0xFF) +#define HV_SYNIC_SINT_COUNT 16 + +enum { + HV_TEST_DEV_SINT_ROUTE_CREATE = 1, + HV_TEST_DEV_SINT_ROUTE_DESTROY, + HV_TEST_DEV_SINT_ROUTE_SET_SINT +}; + +static atomic_t isr_ente...

...vector; > + > + vector = data & HV_SYNIC_SINT_VECTOR_MASK; > + if (vector < 16) > + return 1; > + /* > + * Guest may configure multiple SINTs to use the same vector, so > + * we maintain a bitmap of vectors handled by synic, and a > + * bitmap of vectors with auto-eoi behavoir. The bitmaps are Typo (behavior). > + * updated here, and atomically queried on fast paths. > + */ > + > + if (!(data & HV_SYNIC_SINT_MASKED)) { > + __set_bit(vector, synic->vec_bitmap); > + if (data & HV_SYNIC_SINT_AUTO_EOI) > + __set_bit(vector, s...

...vector; > + > + vector = data & HV_SYNIC_SINT_VECTOR_MASK; > + if (vector < 16) > + return 1; > + /* > + * Guest may configure multiple SINTs to use the same vector, so > + * we maintain a bitmap of vectors handled by synic, and a > + * bitmap of vectors with auto-eoi behavoir. The bitmaps are Typo (behavior). > + * updated here, and atomically queried on fast paths. > + */ > + > + if (!(data & HV_SYNIC_SINT_MASKED)) { > + __set_bit(vector, synic->vec_bitmap); > + if (data & HV_SYNIC_SINT_AUTO_EOI) > + __set_bit(vector, s...

Hi Stef and Alexey I have read some documents about CBQ algorithm from http://www.icir.org/floyd/cbq.html but still have some question about CBQ in Linux . 1. First estimator can estimate how much bandwidth already USED per class. one estimating algorithm is EWMA (exponential weighted moving average), how about Linux implemenatation about estimator? also do you have link for this algorithm? I

On Fri, Oct 09, 2015 at 04:42:33PM +0200, Paolo Bonzini wrote: > You need to add SYNIC vectors to the EOI exit bitmap, so that APICv > (Xeon E5 or higher, Ivy Bridge or newer) is handled correctly. You also > need to check the auto EOI exit bitmap in __apic_accept_irq, and avoid > going through kvm_x86_ops->deliver_posted_interrupt for auto EOI > vectors. Something like > > if...

On Mon, 6 May 2024, openssh at tr.id.au wrote: > Hey Damien, > > > Would something like this help? > > > > Match sessiontype shell > > User foo > > Match remotecommand "none" > > User foo2 > > Match sessiontype exec remotecommand "/rsync" > > User bar > > Match sessiontype subsystem remotecommand "sftp"

Hey Damien, > These changes are against openssh HEAD. If you've applied them against > another version then you might have conflicts. Did patch complain > when you applied the diff? I did a fresh fetch and rebase on master branch from openssh-portable on GitHub before applying the patch. I've also tested with a fresh clone. The patch applied cleanly except for a missing

In pirq_check_eoi_map use the pirq number rather than the Linux irq number to check whether an eoi is needed in the pirq_eoi_map. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Tested-by: Tobias Geiger <tobias.geiger@vido.info> --- drivers/xen/events.c | 2 +- 1 files changed,...