search for: eois

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

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

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

c/s 25336:edd7c7ad1ad2 introduced the concept of a bogus vector, for in irqs delivered through the i8259 PIC after IO-APICs had been set up. However, if supurious PIC vectors are received, many "No irq handler for vector" log messages can be seen on the console. This patch adds to the bogus vector logic to detect spurious PIC vectors and simply ignore them. _mask_and_ack_8259A_irq()

On 11/02/2015 03:16 PM, Paolo Bonzini wrote: > On 26/10/2015 10:56, Andrey Smetanin wrote: >> Hyper-V SynIC is a Hyper-V synthetic interrupt controller. >> >> The test runs on every vCPU and performs the following steps: >> * read from all Hyper-V SynIC MSR's >> * setup Hyper-V SynIC evt/msg pages >> * setup SINT's routing >> * inject SINT's

On 11/02/2015 03:16 PM, Paolo Bonzini wrote: > On 26/10/2015 10:56, Andrey Smetanin wrote: >> Hyper-V SynIC is a Hyper-V synthetic interrupt controller. >> >> The test runs on every vCPU and performs the following steps: >> * read from all Hyper-V SynIC MSR's >> * setup Hyper-V SynIC evt/msg pages >> * setup SINT's routing >> * inject SINT's

Hi, Keir, These patches are rebased version of Yunhong''s original patches, which were sent out before XEN 3.2 was released. These patches enable MSI support and limited MSI-X support in XEN. Here is the original description 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

int.patch: - Supports only level-triggered interrupts. Edge interrupts support will be added shortly (should be fairly simple) - Change polarity trick: in order to reflect the external device''s assertion state, the ioapic pin gets its polarity changed whenever an interrupt occur. So an interrupt is generated when the _external_ line is asserted (then,

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:

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) -

Hyper-V SynIC is a Hyper-V synthetic interrupt controller. The test runs on every vCPU and performs the following steps: * read from all Hyper-V SynIC MSR's * setup Hyper-V SynIC evt/msg pages * setup SINT's routing * inject SINT's into destination vCPU by 'hyperv-synic-test-device' * wait for SINT's isr's completion * clear Hyper-V SynIC evt/msg pages and destroy

Hyper-V SynIC is a Hyper-V synthetic interrupt controller. The test runs on every vCPU and performs the following steps: * read from all Hyper-V SynIC MSR's * setup Hyper-V SynIC evt/msg pages * setup SINT's routing * inject SINT's into destination vCPU by 'hyperv-synic-test-device' * wait for SINT's isr's completion * clear Hyper-V SynIC evt/msg pages and destroy

Christian, the question for you is towards the end... On 09/10/2015 15:39, Denis V. Lunev wrote: > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index 62cf8c9..15c3c02 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -23,13 +23,265 @@ > > #include "x86.h" > #include "lapic.h" > +#include "ioapic.h"

Christian, the question for you is towards the end... On 09/10/2015 15:39, Denis V. Lunev wrote: > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index 62cf8c9..15c3c02 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -23,13 +23,265 @@ > > #include "x86.h" > #include "lapic.h" > +#include "ioapic.h"

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 >

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, 1 insertions(+), 1 deletions(-) diff --git a/drivers/xen/events.c