> But doesn't the interrupt code have to check all interrupt sources on a
> shared line?
well technically the kernel just calls all handers.
> That means checking the non-PV interrupt as well, which
> involves a vmexit (for mmio read).
ok I see what you mean. Yes agreed we should avoid shar
Arjan van de Ven wrote:
>>> shared interrupts aren't a big deal in Linux. at all.
>>> In fact, sharing all PV interrupts to one number is a performance
>>> enhancement ;)
>>>
>>>
>> If you share a PV interrupt with a non-PV interrupt, then for each PV
>> interrupt you have to check wheth
> > shared interrupts aren't a big deal in Linux. at all.
> > In fact, sharing all PV interrupts to one number is a performance
> > enhancement ;)
> >
>
> If you share a PV interrupt with a non-PV interrupt, then for each PV
> interrupt you have to check whether the non-PV interrupt fired. T
Arjan van de Ven wrote:
> On Sun, 2007-02-25 at 07:17 +0200, Avi Kivity wrote:
>
>> Arjan van de Ven wrote:
>>
The easiest thing I can think of is to have the PV disk driver show up
as an actual PCI device and to use a PCI option rom to hijack the
appropriate interrupt.
>>>
On Sun, 2007-02-25 at 07:17 +0200, Avi Kivity wrote:
> Arjan van de Ven wrote:
> >> The easiest thing I can think of is to have the PV disk driver show up
> >> as an actual PCI device and to use a PCI option rom to hijack the
> >> appropriate interrupt.
> >>
> >
> > yeah that's a good plan.
Avi Kivity wrote:
>
> The qemu part is irrelevant as he's generating the interrupts from the
> host kernel directly. And I think that the guest-side driver is a bit
> of overkill.
>
I was thinking of interrupts when I wrote this so it came out garbled.
The qemu part is irrelevant because he's
Daniel P. Berrange wrote:
> FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!)
> support for managing virtual machines running under QEMU or KVM virtualization
> platforms, as well as the existing Xen support.
>
>
Great; as I see it hit FC6-updates I'll give it a shot
Jef wrote:
> Hi all,
> I just have open a sourceforge project named GKVM.
> It's a rather simple gnome interface, that greatly simplify KVM virtual
> machines creation, maintenance and running.
>
Looks like a nice lightweight solution.
Once you have a project home page I can link to it f
Chris Stromblad wrote:
> Hi there,
>
> Just wanted to introduce myself to the list and also ask a few
> questions. My name is Chris, currently living in the UK, nerd by day and
> even more so at night.
>
> Today I thought about playing with KVM for the first time, but without
> much luck. Reading t
Dor Laor wrote:
>>> The easiest thing I can think of is to have the PV disk driver show
>>>
> up
>
>>> as an actual PCI device and to use a PCI option rom to hijack the
>>> appropriate interrupt.
>>>
>> yeah that's a good plan. Being a PCI device also helps with the OS
>> userspace
Arjan van de Ven wrote:
>> The easiest thing I can think of is to have the PV disk driver show up
>> as an actual PCI device and to use a PCI option rom to hijack the
>> appropriate interrupt.
>>
>
> yeah that's a good plan. Being a PCI device also helps with the OS
> userspace knowing which
>> The easiest thing I can think of is to have the PV disk driver show
up
>> as an actual PCI device and to use a PCI option rom to hijack the
>> appropriate interrupt.
>
>yeah that's a good plan. Being a PCI device also helps with the OS
>userspace knowing which module to load; even if the device
Hi there,
Just wanted to introduce myself to the list and also ask a few
questions. My name is Chris, currently living in the UK, nerd by day and
even more so at night.
Today I thought about playing with KVM for the first time, but without
much luck. Reading the archives I noticed someone else wa
13 matches
Mail list logo
