[Qemu-devel] [Bug 893367] Re: HPET supports only one IRQ

No. Looks good to me. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/893367 Title: HPET supports only one IRQ Status in QEMU: Incomplete Bug description: The emulated HPET only supports trigge

Re: [Qemu-devel] [snabb-devel:300] Re: snabbswitch integration with QEMU for userspace ethernet I/O

on Rusty > Russell's specification. The switch<->VM interface would be based > on PCI rather than vhost. > > I _think_ this is the basic idea that Stefano Stabellini and > Julian Stecklina are talking about. Yes. Btw, progress is being made. Albeit a bit slower than expe

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/2013 08:46 AM, Stefan Hajnoczi wrote: > On Wed, May 29, 2013 at 6:02 PM, Julian Stecklina > wrote: >> On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote: >>> The fact that a single switch process has shared memory access &

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote: > The fact that a single switch process has shared memory access to all > guests' RAM is critical. If the switch process is exploited, then that > exposes other guests' data! (Think of a multi-tenant host with guests > belonging to different users.)

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

On 05/29/2013 04:31 PM, Stefan Hajnoczi wrote: > On Wed, May 29, 2013 at 02:32:50PM +0200, Julian Stecklina wrote: >> On 05/28/2013 07:00 PM, Anthony Liguori wrote: >>> We aren't going to support any interface that enables out of tree >>> devices. This is just

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

On 05/28/2013 07:00 PM, Anthony Liguori wrote: > We aren't going to support any interface that enables out of tree > devices. This is just plugins in a different form with even more > downsides. You cannot easily keep track of dirty info, the guest > physical address translation to host is diffic

Re: [Qemu-devel] [snabb-devel:276] Re: snabbswitch integration with QEMU for userspace ethernet I/O

On 05/28/2013 04:42 PM, Luke Gorrie wrote: > On 28 May 2013 13:53, Michael S. Tsirkin > wrote: > > Yes, you can maybe trade some of this latency for power/CPU cycles by > aggressive polling. Doing this in a way that does not waste a lot of > power would be tri

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

On 05/28/2013 03:56 PM, Michael S. Tsirkin wrote: > and in fact that was how vhost worked originally. > There were some issues to be fixed before it worked > without issues, but we do plan to go back to that I think. Do you know why they abandoned this execution model? Julian signature.asc Des

Re: [Qemu-devel] [snabb-devel:276] Re: snabbswitch integration with QEMU for userspace ethernet I/O

On 05/28/2013 02:48 PM, Luke Gorrie wrote: > On 28 May 2013 13:53, Michael S. Tsirkin > wrote: > > Implementing out of process device logic would absolutely be useful for > qemu, for security. > > > This sounds wonderful from my perspective. The whole PCI device

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

On 05/28/2013 01:53 PM, Michael S. Tsirkin wrote: > Implementing out of process device logic would absolutely be useful for > qemu, for security. > > Don't expect it to be zero overhead though, latency overhead > of bouncing each packet through multiple processes would > be especially painful. Cu

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

On 05/28/2013 12:10 PM, Luke Gorrie wrote: > On 27 May 2013 11:34, Stefan Hajnoczi > wrote: > > vhost_net is about connecting the a virtio-net speaking process to a > tun-like device. The problem you are trying to solve is connecting a > virtio-net speakin

[Qemu-devel] [Bug 893367] Re: HPET supports only one IRQ

The offending code seems to be: /* advertise availability of ioapic inti2 */ timer->config |= 0x0004ULL << 32; in hw/hpet.c hpet_reset(). -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.ne

[Qemu-devel] [Bug 893367] [NEW] HPET supports only one IRQ

Public bug reported: The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CP