On Wed, Jan 04, 2017 at 11:33:36AM +0100, Jan Kiszka wrote:
> On 2017-01-03 07:15, Peter Xu wrote:
> > On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote:
> >> On 2016-06-26 03:48, Peter Xu wrote:
> >>> On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
> On 2016-06-25 15:18,
On 2017-01-03 07:15, Peter Xu wrote:
> On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote:
>> On 2016-06-26 03:48, Peter Xu wrote:
>>> On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
On 2016-06-25 15:18, Peter Xu wrote:
> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Ki
On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote:
> On 2016-06-26 03:48, Peter Xu wrote:
> > On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
> >> On 2016-06-25 15:18, Peter Xu wrote:
> >>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
> >
> > [...]
> >
> >>> I
On 21/06/2016 09:47, Peter Xu wrote:
> @@ -3323,6 +3325,31 @@ int kvm_device_msix_deassign(KVMState *s, uint32_t
> dev_id)
> int kvm_arch_fixup_msi_route(struct kvm_irq_routing_entry *route,
> uint64_t address, uint32_t data, PCIDevice *dev)
> {
> +X86IOMMUSta
On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote:
> On 2016-06-26 03:48, Peter Xu wrote:
> > On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
> >> On 2016-06-25 15:18, Peter Xu wrote:
> >>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
> >
> > [...]
> >
> >>> I
On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote:
> On 2016-06-26 03:48, Peter Xu wrote:
> > On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
> >> On 2016-06-25 15:18, Peter Xu wrote:
> >>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
> >
> > [...]
> >
> >>> I
On 2016-06-26 03:48, Peter Xu wrote:
> On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
>> On 2016-06-25 15:18, Peter Xu wrote:
>>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
>
> [...]
>
>>> I have a thought on how to implement the "sink" you have mentioned:
>>>
>>> Fi
On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
> On 2016-06-25 15:18, Peter Xu wrote:
> > On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
[...]
> > I have a thought on how to implement the "sink" you have mentioned:
> >
> > First of all, in KVM, we provide a new KVM_IRQ_
On 2016-06-25 15:18, Peter Xu wrote:
> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
>
> [...]
>
>> For successful remappings, this is fine - it just caches the result in
>> an interrupt route. But what will happen with invalid interrupts?
>>
>> My current understanding is that, bec
On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
[...]
> For successful remappings, this is fine - it just caches the result in
> an interrupt route. But what will happen with invalid interrupts?
>
> My current understanding is that, because the translation happens on
> activation of
On 2016-06-21 09:47, Peter Xu wrote:
> In split irqchip mode, IOAPIC is working in user space, only update
> kernel irq routes when entry changed. When IR is enabled, we directly
> update the kernel with translated messages. It works just like a kernel
> cache for the remapping entries.
>
> Since
In split irqchip mode, IOAPIC is working in user space, only update
kernel irq routes when entry changed. When IR is enabled, we directly
update the kernel with translated messages. It works just like a kernel
cache for the remapping entries.
Since KVM irqfd is using kernel gsi routes to deliver i
12 matches
Mail list logo
