On 13/01/15 17:18, Ian Campbell wrote:
> On Tue, 2015-01-13 at 16:57 +, Julien Grall wrote:
>> (CC Jan)
>
> I think you forget, I added him.
>
>> @@ -49,6 +49,21 @@ int domain_vtimer_init(struct domain *d)
>> {
>> d->arch.phys_timer_base.offset = NOW();
>> d->arch.v
On 13/01/15 16:46, Ian Campbell wrote:
>> We need to track everything for interrupt assignment to a guest/dom0. So
>> if the guest ask for a free vIRQ we can give it directly.
>
> Makes sense.
>
> In that case you 0/4 mail doesn't fully describe the use case for the
> series, since it talks about
On 13/01/15 16:57, Julien Grall wrote:
> (CC Jan)
Forgot to really CC Jan for the bool stuff.
> Hi Ian,
>
> On 13/01/15 16:46, Ian Campbell wrote:
>>> vgic_reserve_irq returns a boolean:
>>
>> Please use true/false then.
>>
>> In Xen we have xen/stdbool.h which differs from normal stdboot.h. I'm
On Tue, 2015-01-13 at 16:57 +, Julien Grall wrote:
> (CC Jan)
I think you forget, I added him.
> @@ -49,6 +49,21 @@ int domain_vtimer_init(struct domain *d)
> {
> d->arch.phys_timer_base.offset = NOW();
> d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0
(CC Jan)
Hi Ian,
On 13/01/15 16:46, Ian Campbell wrote:
>> vgic_reserve_irq returns a boolean:
>
> Please use true/false then.
>
> In Xen we have xen/stdbool.h which differs from normal stdboot.h. I'm
> not sure what the rules are for use.
Jan please correct me if I'm wrong, xen/stdbool.h has
On Tue, 2015-01-13 at 16:27 +, Julien Grall wrote:
> Hi Ian,
>
> On 13/01/15 15:51, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 14:43 +, Julien Grall wrote:
> >> While it's easy to know which hardware IRQ is assigned to a domain, there
> >> is no way to know which IRQ is emulated by Xen
Hi Ian,
On 13/01/15 15:51, Ian Campbell wrote:
> On Fri, 2014-12-12 at 14:43 +, Julien Grall wrote:
>> While it's easy to know which hardware IRQ is assigned to a domain, there
>> is no way to know which IRQ is emulated by Xen for a specific domain.
>
> It seems you are tracking all valid int
On Fri, 2014-12-12 at 14:43 +, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which IRQ is emulated by Xen for a specific domain.
It seems you are tracking all valid interrupts, including hardware ones,
not just those for emu
On 15/12/14 16:07, Julien Grall wrote:
> On 15/12/14 15:32, Stefano Stabellini wrote:
>> On Fri, 12 Dec 2014, Julien Grall wrote:
>>> +spin_lock_init(&d->arch.vgic.lock);
>>
>> you should probably explain in the commit message the reason why you are
>> making changes to the vgic lock
>
> Actua
Hi Stefano,
On 15/12/14 15:32, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> +spin_lock_init(&d->arch.vgic.lock);
>
> you should probably explain in the commit message the reason why you are
> making changes to the vgic lock
Actually the domain vgic lock was never u
On Fri, 12 Dec 2014, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which IRQ is emulated by Xen for a specific domain.
>
> Introduce a bitmap to keep track of every vIRQ used by a domain. This
> will be used later to find free v
11 matches
Mail list logo
