Michael Tsirkin found a race condition in the irqfd code where we may
allow the underlying eventfd object to race with the rmmod of kvm.ko.
Since we now use eventfd_notifier for irqfd, lets add a struct module *owner
field to properly maintain references to our registered signal handlers.
Found-b
irqfd and its underlying implementation, eventfd, currently utilize
the embedded wait-queue in eventfd for signal notification. The nice thing
about this design decision is that it re-uses the existing
eventfd/wait-queue code and it generally works wellwith several
limitations.
One of the lim
(Applies to kvm.git/master:c27b64a0)
For more details, please read the patch headers. This series adds
a new feature to eventfd (explicit notifications) which addresses
wqh based limitations, as well as provides fixes for several issues
in irqfd pointed out by Michael Tsirkin. You can find refer
On Fri, 2009-06-12 at 13:12 -0300, Lucas Meneghel Rodrigues wrote:
> The 'autotest' subtest of KVM got broke during the merge, since the new
> logging system introduces new line prefixes on the autotest output. This
> patch series fixes this subtest. It consists on:
>
> * Fix a a few bad long lin
On Sat, 2009-06-13 at 05:13 -0400, Michael Goldish wrote:
> - "Lucas Meneghel Rodrigues" wrote:
>
> > The 'autotest' kvm subtest was relying on autotest output, that
> > now has the logging line prefixes. The logging line prefixes
> > breaks the results parser, so we would either have to make
Lucas Meneghel Rodrigues wrote:
> On Fri, 2009-06-12 at 10:43 -0400, David Huff wrote:
>> This patch adds the processes_command function to the preprocessor which
>> will run custom scripts before and after a test is executed.
>>
>> processes_command will export all test parameters as environmental
On Sat, 2009-06-13 at 05:00 -0400, Michael Goldish wrote:
> - "Lucas Meneghel Rodrigues" wrote:
>
> > Signed-off-by: Lucas Meneghel Rodrigues
> > ---
> > client/tests/kvm/kvm_config.py | 14 +++---
> > client/tests/kvm/kvm_tests.py | 12 ++--
> > 2 files changed, 13 ins
On Mon, Jun 15, 2009 at 03:33:41PM -0500, Anthony Liguori wrote:
> The basic issue is that:
>
> migrate_fd_put_ready():bdrv_flush_all();
>
> Does:
>
> block.c:
>
> foreach block driver:
> drv->flush(bs);
>
> Which in the case of raw, is just fsync(s->fd).
>
> Any submitted request is not queu
On Fri, 2009-06-12 at 10:43 -0400, David Huff wrote:
> This patch adds the processes_command function to the preprocessor which
> will run custom scripts before and after a test is executed.
>
> processes_command will export all test parameters as environmental variables
> for passing parameters t
The basic issue is that:
migrate_fd_put_ready():bdrv_flush_all();
Does:
block.c:
foreach block driver:
drv->flush(bs);
Which in the case of raw, is just fsync(s->fd).
Any submitted request is not queued or flushed which will lead to the
request being dropped after the live migration.
This patch adds the processes_command function to the preprocessor which
will run custom scripts before and after a test is executed.
processes_command will export all test parameters as environmental variables
for passing parameters to a custom script.
processes_command uses parameters defined i
Beth Kon wrote:
> kvm.h has
>
> #define KVM_SET_GUEST_DEBUG _IOW(KVMIO, 0x9b, struct
> kvm_guest_debug)
>
> and
>
> #define KVM_IA64_VCPU_SET_STACK _IOW(KVMIO, 0x9b, void *)
>
> Seems that these could conflict?
Argh...
The IA64 world also collides with KVM_NMI - though I have no clu
On Mon, 15 Jun 2009, Marcelo Tosatti wrote:
> This allows use of the powerful ftrace infrastructure.
>
> See Documentation/trace/ for usage information.
>
> Signed-off-by: Marcelo Tosatti
>
> Index: kvm/arch/x86/kvm/svm.c
> ===
>
Add two new step file test parameters:
- keep_screendump_history: if equals 'yes', screendump history is saved in
test.debugdir/barrier_history in JPG format. Each screendump taken by the
test is saved if it differs from the previous screendump. By default, when
a barrier succeeds all histo
This should be rather harmless because the history does not take up much space,
and is only kept for the failed barriers in failed tests, by default.
It should significantly ease debugging of failed step file tests.
Signed-off-by: Michael Goldish
---
client/tests/kvm/kvm_tests.cfg.sample |2
Currently parameters for barrier_2() are extracted from 'params' in the main
run_steps() test routine, and then passed to barrier_2().
Instead, let barrier_2() extract parameters from 'params' as it sees fit.
This will make adding new parameters slightly easier and cleaner.
Signed-off-by: Michael
The name 'debug_dir' makes it clearer that it corresponds to test.debugdir.
Signed-off-by: Michael Goldish
---
client/tests/kvm/kvm_guest_wizard.py | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/client/tests/kvm/kvm_guest_wizard.py
b/client/tests/k
The following patches make some changes to step file tests:
* Rename parameter output_dir in barrier_2() to debug_dir.
* Move some code from run_steps() into barrier_2().
* Add a new feature (keep_screendump_history) which allows the user to see
exactly what went wrong with a step file test. Curr
Same spirit of what has already been done for the generic code.
Fold libkvm.c into qemu-kvm-x86.c. handle_tpr_access becomes
kvm_handle_tpr_access, to avoid name clash.
Signed-off-by: Glauber Costa
---
Makefile.target |2 +-
qemu-kvm-x86.c | 652 ++
kvm.h has
#define KVM_SET_GUEST_DEBUG _IOW(KVMIO, 0x9b, struct kvm_guest_debug)
and
#define KVM_IA64_VCPU_SET_STACK _IOW(KVMIO, 0x9b, void *)
Seems that these could conflict?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.
On 6/15/09, Avi Kivity wrote:
> On 06/15/2009 09:12 PM, Anthony Liguori wrote:
>
> >
> > 2) Whenever the default machine type changes in a guest-visible way,
> introduce a new machine type
> >
>
> s/whenever/qemu stable release/
>
>
> > - Use explicit versions in name: pc-v1, pc-v2
> >
>
> pc-q
This allows use of the powerful ftrace infrastructure.
See Documentation/trace/ for usage information.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/lapic.c
===
--- kvm.orig/arch/x86/kvm/lapic.c
+++ kvm/arch/x86/kvm/lapic.
Return EOPNOTSUPP for KVM_TRACE_ENABLE/PAUSE/DISABLE ioctls.
Signed-off-by: Marcelo Tosatti
Index: kvm/virt/kvm/kvm_main.c
===
--- kvm.orig/virt/kvm/kvm_main.c
+++ kvm/virt/kvm/kvm_main.c
@@ -2367,7 +2367,7 @@ static long kvm_dev_i
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Avi Kivity wrote:
On 06/15/2009 09:12 PM, Anthony Liguori wrote:
2) Whenever the default machine type changes in a guest-visible way,
introduce a new machine type
s/whenever/qemu stable release/
- Use explicit versions in name: pc-v1, pc-v2
pc-qemu-0.10?
This is similar to a hardware v
On 06/15/2009 09:12 PM, Anthony Liguori wrote:
2) Whenever the default machine type changes in a guest-visible way,
introduce a new machine type
s/whenever/qemu stable release/
- Use explicit versions in name: pc-v1, pc-v2
pc-qemu-0.10?
This is similar to a hardware vendor's model numbe
Mark McLoughlin wrote:
So long as the restrictions would be known to the management app via
some "what slots are available" mechanism in qemu, that sounds fine.
I'm not sure a "what slots are available" mechanism is as straight
forward as has been claimed. It doesn't matter though because
On Mon, 2009-06-15 at 18:05 +0300, Avi Kivity wrote:
> On 06/15/2009 05:24 PM, Anthony Liguori wrote:
> > Dor Laor wrote:
> >> Libvirt does not support r2d. I hope it won't start to support it.
> >
> > It supports mips, sparc, and ppc machines now. I don't see why it
> > wouldn't support r2d. Fo
On Mon, 2009-06-15 at 18:12 +0300, Dor Laor wrote:
> > It doesn't want to. As Mark said, libvirt just wants to be able to ensure
> > a stable guest ABI, of which stable PCI addresses is one aspect. This does
> > not imply libvirt wants to allocate the PCI addresses, just that it wants
> > a way to
The PCI code already knows about option ROMs, so we just need to
mmap some space for it, load it with a copy of the contents, and
complete the plubming to the generic code.
With this a Linux guest can get access to the ROM contents via
/sys/bus/pci/devices//rom. This might also enable the BIOS
to
On Mon, Jun 15, 2009 at 6:35 AM, Alexey Eromenko wrote:
>
> - "Martin Bligh" wrote:
>
>> On Wed, Jun 10, 2009 at 4:01 AM, Alexey Eromenko
>> wrote:
>> >
>> > Even better would be to use "/usr/bin/python2".
>>
>> That doesn't seem to exist, on Ubuntu at least.
>>
>
> Red Hat systems have it. "/
On 06/15/2009 06:20 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I would prefer explicit names (pci_addr, lun, etc.) but would be okay
with generic names too.
I think having a generic address has a lot of value in terms of code
implementation. Otherwise, the valid options for -drive become
On 06/15/2009 06:25 PM, Michael Tokarev wrote:
Avi Kivity wrote:
On 06/15/2009 05:15 PM, Erik Jacobson wrote:
[]
So if I understand what you're saying: best not to use kvm guests
for build
servers with pre-Nehalem processors.
pre-Nehalem / pre-Barcelona, > 4 vcpus, yes.
How about 2 vcpus
Avi Kivity wrote:
On 06/15/2009 05:15 PM, Erik Jacobson wrote:
[]
So if I understand what you're saying: best not to use kvm guests for build
servers with pre-Nehalem processors.
pre-Nehalem / pre-Barcelona, > 4 vcpus, yes.
How about 2 vcpus, and how about AMD processors ?
Thanks
/mjt
--
Avi Kivity wrote:
I would prefer explicit names (pci_addr, lun, etc.) but would be okay
with generic names too.
I think having a generic address has a lot of value in terms of code
implementation. Otherwise, the valid options for -drive become
context-sensitive which is going to be annoying
On 06/15/2009 05:58 PM, Ryan Harper wrote:
* Izik Eidus [2009-06-10 11:25]:
RFC move to dirty bit tracking using the page table dirty bit (v2)
Where is this series at? Did you want me to test one of the ept dirty
tracking patches for that hugepage+ept+local migration bug?
Th
On 06/15/2009 06:12 PM, Dor Laor wrote:
It doesn't want to. As Mark said, libvirt just wants to be able to
ensure
a stable guest ABI, of which stable PCI addresses is one aspect. This
does
not imply libvirt wants to allocate the PCI addresses, just that it
wants
a way to keep them stable. All e
Daniel P. Berrange wrote:
On Mon, Jun 15, 2009 at 10:03:22AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
I'm not at all arguing against pci_addr. I'm arguing about how libvirt
should use it with respect to the "genesis" use-case where libvirt has
no specific reason to ch
On 06/15/2009 06:07 PM, Anthony Liguori wrote:
Avi Kivity wrote:
I'd object to any implicit addressing rules. If we have to say
target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of
index=8345345235 so be it.
The next observation is that while we expand the SCSI addressing, the
cur
Avi Kivity wrote:
However this may end up, isn't it offtopic? Whatever we do we have to
support both pci_addr= and default placement, so we can push this
discussion to livirt-devel and bid them godspeed.
I'm not sure how we got here but yeah, let's table this part of the
discussion.
Regard
Michael S. Tsirkin wrote:
And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be
more straightforward to have capability bits which can be switched on
and off independently rather than trying to fit unrelated features into
a machine type? IMO it only seems more work at first, an
On Mon, Jun 15, 2009 at 10:03:22AM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
> >>I'm not at all arguing against pci_addr. I'm arguing about how libvirt
> >>should use it with respect to the "genesis" use-case where libvirt has
> >>no specific reason to choose one PCI slot over
Avi Kivity wrote:
I'd object to any implicit addressing rules. If we have to say
target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of
index=8345345235 so be it.
The next observation is that while we expand the SCSI addressing, the
current propose flattens the PCI hierarchy (i.e. pc
On 06/15/2009 05:24 PM, Anthony Liguori wrote:
Dor Laor wrote:
Libvirt does not support r2d. I hope it won't start to support it.
It supports mips, sparc, and ppc machines now. I don't see why it
wouldn't support r2d. For ppcemb, I expect this same problem to
occur. This sort of restricti
Michael S. Tsirkin wrote:
I'm not at all arguing against pci_addr. I'm arguing about how libvirt
should use it with respect to the "genesis" use-case where libvirt has
no specific reason to choose one PCI slot over another. In that case,
I'm merely advocating that we want to let QEMU make
* Izik Eidus [2009-06-10 11:25]:
> RFC move to dirty bit tracking using the page table dirty bit (v2)
>
Where is this series at? Did you want me to test one of the ept dirty
tracking patches for that hugepage+ept+local migration bug?
--
Ryan Harper
Software Engineer; Linux Technology Center
I
On Mon, 2009-06-15 at 09:35 -0400, Alexey Eromenko wrote:
> - "Martin Bligh" wrote:
>
> > On Wed, Jun 10, 2009 at 4:01 AM, Alexey Eromenko
> > wrote:
> > >
> > > Even better would be to use "/usr/bin/python2".
> >
> > That doesn't seem to exist, on Ubuntu at least.
> >
>
> Red Hat systems
On Mon, Jun 15, 2009 at 09:24:32AM -0500, Anthony Liguori wrote:
> Dor Laor wrote:
>> Libvirt does not support r2d. I hope it won't start to support it.
>
> It supports mips, sparc, and ppc machines now. I don't see why it
> wouldn't support r2d. For ppcemb, I expect this same problem to occur.
On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
>> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
>>
Eventually the default configuration becomes increasingly unusable
and you need a new baseline. You must still be able to fall bac
Dor Laor wrote:
Libvirt does not support r2d. I hope it won't start to support it.
It supports mips, sparc, and ppc machines now. I don't see why it
wouldn't support r2d. For ppcemb, I expect this same problem to occur.
This sort of restriction is going to be common with embedded boards.
On 06/15/2009 05:15 PM, Erik Jacobson wrote:
What is the host cpu type? On pre-Nehalem/Barcelona processors kvm has
poor scalability in mmu intensive workloads like kernel builds.
Thanks for getting back to me.
Today is pretty booked but I'm going to go find a Nehalem system and try to
On Mon, Jun 15, 2009 at 6:43 AM, Avi Kivity wrote:
> (I'd be quite happy constructing the entire machine config on the command
> line, but I realize it's just me)
as a user-only (well, i'm a developer, but don't meddle in kernel
affairs since 0.99pl9); I also like that kvm is totally CLI-managed.
Mark McLoughlin wrote:
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
Eventually the
default configuration becomes increasingly unusable and you need a new
baseline. You must still be able to fall back to the old baseline for
older guests. I don't think games with configuration
> What is the host cpu type? On pre-Nehalem/Barcelona processors kvm has
> poor scalability in mmu intensive workloads like kernel builds.
Thanks for getting back to me.
Today is pretty booked but I'm going to go find a Nehalem system and try to
run similar tests to compare. I'll post my resu
Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
How would qemu know which slots to optimize for?
In practice, I don't see that as a real problem. We should (a) add
an ioapic and four more pci links (b) recommend that slots be
assigned in ascending ord
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
> > I think the point is that you don't need version numbers if you
> > have a
> > proper device tree.
> >
> >
> How do you add a new
On 06/15/2009 04:45 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
It's not at all that simple. SCSI has a hierarchical address
mechanism with 0-7 targets but then potentially multiple LUNs per
target. Today, we always emulate a single LUN per ta
Avi Kivity wrote:
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
How would qemu know which slots to optimize for?
In practice, I don't see that as a real problem. We should (a) add an
ioapic and four more pci links (b) recommend that slots be assigned in
ascending order, and everything works
On 06/15/2009 04:23 PM, Gleb Natapov wrote:
Also fix "info cpus" to show correct halt status with in kernel irq chip.
Applied all, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mess
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to already applied version*
- ensure allocations (might_sleep) are out of atomic context
- centralize consumption of vcpu->request bits
To ensure vcpu's come out of guest
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to already applied version*
- remove dependency to KVM_REQ_MMU_RELOAD in generic code
- remove explicit barrier after test_and_clear_bit as it is implied
- ensure the wait
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
kvm on s390 formerly ignored vcpu->cpu.
This patch adds set/unset vcpu->cpu in kvm_arch_vcpu_load/put to allow
further architecture unification e.g. let generic code not find -1 on
From: Christian Ehrhardt
As requested this is a rebased patch on top of the already applied v3
of the patch series.
*updates to applied version*
- remove dependency to KVM_REQ_MMU_RELOAD in generic code
- remove explicit barrier after test_and_clear_bit as it is implied
- ensure the wait_on_bit
Avi Kivity wrote:
Marcelo Tosatti wrote:
(continued below)
Anyway, yeah, the set request / wait mechanism you implement here is
quite similar to the idea mentioned earlier that could be used for
x86.
Just get rid of this explicit KVM_REQ_MMU_RELOAD knowledge in
arch-independent code pl
On 06/15/2009 04:24 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Certainly preferable to -baseline.
This is pretty easy to maintain with config files.
Let's not tie the two together.
I mentioned it because it suggests a good transition. We at least
have to think through how things map t
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the com
Avi Kivity wrote:
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
It's not at all that simple. SCSI has a hierarchical address
mechanism with 0-7 targets but then potentially multiple LUNs per
target. Today, we always emulate a single LUN per target but if we
ever wanted to support more than
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
then turns on the power. Command line options are the parts lying
around when we start.
btw, -drive needs to be separated:
-controller type=lsi1234,pci_addr=foobar,name=blah
-drive file=foo.img,controller=blah,index=0
-drive file=bar.img,
- "Martin Bligh" wrote:
> On Wed, Jun 10, 2009 at 4:01 AM, Alexey Eromenko
> wrote:
> >
> > Even better would be to use "/usr/bin/python2".
>
> That doesn't seem to exist, on Ubuntu at least.
>
Red Hat systems have it. "/usr/bin/python2" is a symlink to "/usr/bin/python"
(which is python
Avi Kivity wrote:
Certainly preferable to -baseline.
This is pretty easy to maintain with config files.
Let's not tie the two together.
I mentioned it because it suggests a good transition. We at least have
to think through how things map to the post-config file world regardless
of whet
Avi Kivity wrote:
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command
line
flags.
qemu -show-available-pci-sl
Remove redundant check.
Signed-off-by: Gleb Natapov
---
hw/apic.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index f186202..eac54fd 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -471,8 +471,7 @@ static void apic_init_ipi(APICState *s)
s-
Signed-off-by: Gleb Natapov
---
qemu-kvm-ia64.c |2 --
qemu-kvm-x86.c |2 --
qemu-kvm.c |1 -
3 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/qemu-kvm-ia64.c b/qemu-kvm-ia64.c
index 234602c..477d24c 100644
--- a/qemu-kvm-ia64.c
+++ b/qemu-kvm-ia64.c
@@ -35,7 +35,
And set env->halted based on the value to show accurate vcpu state in
QEMU monitor.
Signed-off-by: Gleb Natapov
---
qemu-kvm.c | 27 +++
qemu-kvm.h |2 ++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 5fa7154..3ae4b45
Remove its use from kvm code.
Signed-off-by: Gleb Natapov
---
qemu-kvm-x86.c |3 +--
qemu-kvm.c |3 ---
vl.c |1 -
3 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 6865385..5460136 100644
--- a/qemu-kvm-x86.c
+++ b/qem
Signed-off-by: Gleb Natapov
---
qemu-kvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 2aeb17c..ec911ef 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -412,7 +412,7 @@ static int kvm_main_loop_cpu(CPUState *env)
if (env->kvm_cp
The call is done from vcpu thread.
Signed-off-by: Gleb Natapov
---
qemu-kvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 7676e02..5fa7154 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -399,7 +399,7 @@ static int kvm_main_loop_cpu(CPUStat
To be consistent with other function naming.
Signed-off-by: Gleb Natapov
---
qemu-kvm-ia64.c |4 ++--
qemu-kvm-x86.c|4 ++--
qemu-kvm.h|2 ++
target-i386/machine.c |6 +++---
target-ia64/machine.c |4 ++--
5 files changed, 11 insertions(+), 9 deletio
Also fix "info cpus" to show correct halt status with in kernel irq chip.
I removed patch that uses on_vcpu() for init/sipi handling for now.
Gleb Natapov (8):
env->kvm_cpu_state.init is always zero here.
Do not use env->halted to decide where halted state should be
handled.
Call kvm_ar
Use kvm_irqchip_in_kernel() for that. If irq chip is not handled by
userspace kernel should be entered even when CPU is halted.
Signed-off-by: Gleb Natapov
---
hw/apic.c |3 +--
qemu-kvm.c |6 +++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
in
While trying to get Hyper-V running, I realized that the interrupt injection
mechanisms that are in place right now are not 100% correct.
This patch makes nested SVM's interrupt injection behave more like on a
real machine.
v2 calls BUG_ON when svm_set_irq is called with GIF=0
Signed-off-by: Ale
SVM adds another way to do INVLPG by ASID which Hyper-V makes use of,
so let's implement it!
For now we just do the same thing invlpg does, as asid switching
means we flush the mmu anyways. That might change one day though.
v2 makes invlpga do the same as invlpg, not flush the whole mmu
Signed-o
Hyper-V uses some MSRs, some of which are actually reserved for BIOS usage.
But let's be nice today and have it its way, because otherwise it fails
terribly.
v2 changes:
- remove the 0x4081 MSR definition
- add pr_unimpl() on unimplemented writes
Signed-off-by: Alexander Graf
---
arch/
Hyper-V tried to access MSR_IGNNE, so let's at least have a definition
for it in our headers.
Signed-off-by: Alexander Graf
---
arch/x86/include/asm/msr-index.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-in
Now that we have nested SVM in place, let's make use of it and virtualize
something non-kvm.
The first interesting target that came to my mind here was Hyper-V.
This patchset makes Windows Server 2008 boot with Hyper-V, which runs
the "dom0" in virtualized mode already. It hangs somewhere in IDE c
Avi Kivity wrote:
On 06/15/2009 03:45 PM, Anthony Liguori wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yes, the user build the machine using the command line and monitor
(or, in 2017, the mach
Hi,
Yes, the user build the machine using the command line and monitor
(or, in 2017, the machine configuration file),
Considering pbrook just posted a machine config for arm, I think it
would be rather sad if pc wasn't converted to it by 2017...
It shouldn't last until 2017, but the proces
On 06/15/2009 03:48 PM, Anthony Liguori wrote:
device tree lacking said attribute, distinguish between a device tree
from an old version of qemu (i.e. use the old default) and a partial
device tree from the VM manager (i.e. use the new default) ?
-baseline 0.10
That's a version number :-)
(I
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line
flags.
qemu -show-available-pci-slots
Why does the us
Anthony Liguori writes:
> Avi Kivity wrote:
>> On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
>>>
>>> Yep, most people seem to agree
On 06/15/2009 03:45 PM, Anthony Liguori wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yes, the user build the machine using the command line and monitor
(or, in 2017, the machine configuration f
On 06/15/2009 03:41 PM, Anthony Liguori wrote:
Yep, most people seem to agree that it makes sense to allow this, but
some believe it should only be via a machine description file, not the
command line.
I don't understand this opposition. It's clear a machine config file
is a long way in our f
On Mon, Jun 15, 2009 at 08:08:18AM -0400, Gregory Haskins wrote:
> >> @@ -123,6 +124,7 @@ irqfd_wakeup(wait_queue_t *wait, unsigned mode, int
> >> sync, void
> >> *key)
> >>
> >> cleanup_srcu_struct(&irqfd->srcu);
> >> kfree(irqfd);
> >> + module_put
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line
flags.
qemu -show-available-pci-slots
(the qemu equivalent to KVM_CHECK_EXTENSION)
--
error compiling committee.
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command line
flags.
qemu -show-available-pci-slots
Why does the user care?
Let QEMU allocate the PCI slot,
Markus Armbruster wrote:
Avi Kivity writes:
Paul/Anthony, can we have -vga pci_addr=, -usb-controller pci_addr=,
and -drive pci_addr= (and later, -disk-controller)? Stalling while
waiting for the ultimate config file is only generating pain and
out-of-tree patches.
Yup.
I got bit-r
Avi Kivity wrote:
On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
I think the point is that you don't need version numbers if you
have a
proper device tree.
How do you add a new attribute to the device tree and, when a supplied
device tree lacking said attribute, distinguish between
Avi Kivity wrote:
On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote:
On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote:
However, in order to retain compat for that SCSI device (e.g. ensuring
the PCI address doesn't change as other devices are added an removed),
we're back to the
On Mon, Jun 15, 2009 at 02:56:42PM +0300, Avi Kivity wrote:
> On 06/15/2009 02:48 PM, Michael S. Tsirkin wrote:
>>> A slot needs to be configured in ACPI,
>>>
>>
>> Can we configure all possible 32 slots?
>>
>
> That's what we do. But one is always taken. In the future, perhaps more.
>
Avi Kivity writes:
> (adding cc)
>
> On 06/15/2009 02:35 PM, Markus Armbruster wrote:
>> Not really. QEMU gives just the host bridge a fixed slot[*]. All the
>> other slots are available.
>>
>
> qemu needs to export these two bits of information: the first free
> slot and the number of slot
1 - 100 of 148 matches
Mail list logo
