On Tue, 14 Feb 2012, Paul Brook wrote:
> > Yes, you are right. Also considering that we are only calling
> > slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
> > the !CONFIG_SLIRP dummy version of the function.
>
> Looks reasonable to me. Unfortunately I can't remember which
> Yes, you are right. Also considering that we are only calling
> slirp_update_timeout if CONFIG_SLIRP is defined, there is no need for
> the !CONFIG_SLIRP dummy version of the function.
Looks reasonable to me. Unfortunately I can't remember which combination of
headless VM and timer configs cau
On Fri, 10 Feb 2012, Paul Brook wrote:
> > +#ifdef CONFIG_SLIRP
> > +static inline void slirp_update_timeout(uint32_t *timeout)
> > +{
> > +*timeout = MIN(1000, *timeout);
> > +}
> > +#else
> > +static inline void slirp_update_timeout(uint32_t *timeout) { }
> > +#endif
>
> Shouldn't we be test
> +#ifdef CONFIG_SLIRP
> +static inline void slirp_update_timeout(uint32_t *timeout)
> +{
> +*timeout = MIN(1000, *timeout);
> +}
> +#else
> +static inline void slirp_update_timeout(uint32_t *timeout) { }
> +#endif
Shouldn't we be testing whether slirp is actually in use? I doubt many people
On Fri, 10 Feb 2012, Jan Kiszka wrote:
> On 2012-02-10 12:18, Paolo Bonzini wrote:
> > On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
> >> I think you are right and the right thing to do would be blocking
> >> indefinitely.
> >> However if slirp doesn't support it, we could have a timeout of 100
On 2012-02-10 12:18, Paolo Bonzini wrote:
> On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
>> I think you are right and the right thing to do would be blocking
>> indefinitely.
>> However if slirp doesn't support it, we could have a timeout of 1000 if
>> CONFIG_SLIRP, otherwise block indefinitel
On 02/10/2012 12:19 PM, Stefano Stabellini wrote:
I think you are right and the right thing to do would be blocking
indefinitely.
However if slirp doesn't support it, we could have a timeout of 1000 if
CONFIG_SLIRP, otherwise block indefinitely.
You could add a similar hack to qemu_bh_update_ti
On Fri, 10 Feb 2012, Paul Brook wrote:
> > >> > At least the floppy DMA engine is fine with it, it uses idle bottom
> > >> > halves (which are a hack and could be replaced by timers, but that's
> > >> > not relevant now).
> > >
> > > I thought idle bottom halves were one of the things that made
> >> > At least the floppy DMA engine is fine with it, it uses idle bottom
> >> > halves (which are a hack and could be replaced by timers, but that's
> >> > not relevant now).
> >
> > I thought idle bottom halves were one of the things that made this timout
> > necessary. How else are they go
On 02/10/2012 10:52 AM, Paul Brook wrote:
> At least the floppy DMA engine is fine with it, it uses idle bottom
> halves (which are a hack and could be replaced by timers, but that's not
> relevant now).
I thought idle bottom halves were one of the things that made this timout
necessary. How
> On 02/10/2012 01:26 AM, Paul Brook wrote:
> > The reason we have this is because there are bits of code that rely on
> > polling. IIRC slirp and the floppy DMA engine were the main culprits.
> > qemu_calculate_timeout is an ugly hack to poll at least once a second,
> > allowing the guest to make
On 02/10/2012 01:26 AM, Paul Brook wrote:
The reason we have this is because there are bits of code that rely on
polling. IIRC slirp and the floppy DMA engine were the main culprits.
qemu_calculate_timeout is an ugly hack to poll at least once a second,
allowing the guest to make forward progres
> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.
No.
The reason we have this is because there are bits of code that rely on
polling. IIRC slirp and the floppy DMA engine were the main culprits.
qemu_calculate_timeout is
There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.
Signed-off-by: Stefano Stabellini
---
qemu-timer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index 8c8bbc3..3207e40 1
14 matches
Mail list logo
