On Tue, Dec 8, 2020 at 8:11 AM Stefan Hajnoczi wrote:
>
> On Thu, Oct 22, 2020 at 05:29:16PM +0100, Fam Zheng wrote:
> > On Tue, 2020-10-20 at 09:34 +0800, Zhenyu Ye wrote:
> > > On 2020/10/19 21:25, Paolo Bonzini wrote:
> > > > On 19/10/20 14:40, Zhenyu Ye wrote:
> > > > > The kernel backtrace fo
On 06/07/2011 04:17 PM, Anthony Liguori wrote:
On 05/16/2011 01:45 PM, Glauber Costa wrote:
This patch adds a dummy legacy ISA device whose responsibility is to
deploy sgabios, an option rom for a serial graphics adapter.
The proposal is that this device is always-on when -nographics,
but can
]
[v3: cleanups and documentation, per list suggestions ]
Signed-off-by: Glauber Costa
---
Makefile.target |2 +-
hw/pc.c |9
hw/sga.c| 56 +++
3 files changed, 66 insertions(+), 1 deletions(-)
create mode
On Fri, May 13, 2011 at 10:43:33AM +0200, Markus Armbruster wrote:
> Glauber Costa writes:
>
> > This patch adds a dummy legacy ISA device whose responsibility is to
> > deploy sgabios, an option rom for a serial graphics adapter.
> > The proposal is that this
]
Signed-off-by: Glauber Costa
---
Makefile.target |2 +-
hw/pc.c |4
hw/pc.h |3 +++
hw/sga.c| 31 +++
4 files changed, 39 insertions(+), 1 deletions(-)
create mode 100644 hw/sga.c
diff --git a/Makefile.target b
working fine.
Signed-off-by: Glauber Costa
---
hw/qdev.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 1aa1ea0..21ef075 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -108,6 +108,10 @@ DeviceState *qdev_create(BusState *bus, const char *name
This patch adds a dummy legacy ISA device whose responsibility is to
deploy sgabios, an option rom for a serial graphics adapter.
The proposal is that this device is always-on when -nographics,
but can otherwise be enable in any setup when -device sga is used.
Signed-off-by: Glauber Costa
On Wed, 2011-05-04 at 16:46 +0300, Gleb Natapov wrote:
> On Wed, May 04, 2011 at 10:36:12AM -0300, Glauber Costa wrote:
> > On Wed, 2011-05-04 at 06:09 -0300, Marcelo Tosatti wrote:
> > > On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> >
On Wed, 2011-05-04 at 06:09 -0300, Marcelo Tosatti wrote:
> On Wed, May 04, 2011 at 04:06:59AM -0400, Ulrich Obergfell wrote:
> >
> > Hi Marcelo,
> >
> > > Whats prev_period for, since in practice the period will not change
> > > between interrupts (OS programs comparator once, or perhaps twice
On Tue, 2011-05-03 at 16:03 -0300, Marcelo Tosatti wrote:
> On Thu, Apr 28, 2011 at 04:25:00PM +0200, Ulrich Obergfell wrote:
> > Loss of periodic timer interrupts caused by delayed callbacks and by
> > interrupt coalescing is compensated by gradually injecting additional
> > interrupts during subs
On Tue, 2011-04-19 at 13:06 +0200, Jan Kiszka wrote:
> kvmclock is represented by two feature bits. Therefore, lookup_feature
> needs to continue its search even after the first match. Enhance it
> accordingly and switch to a bool return type at this chance.
>
> Signed-off-by: Jan Kiszka
> ---
>
On Tue, 2011-04-12 at 14:19 -0500, Anthony Liguori wrote:
> On 04/12/2011 01:47 PM, Glauber Costa wrote:
> > For sure, but if we had this discussion a while ago,
> > sgabios wouldn't exist back then, and now it does =p
>
> Actually, it's been around for ages :-)
&g
On Tue, 2011-04-12 at 13:31 -0500, Anthony Liguori wrote:
> On 04/12/2011 01:13 PM, Glauber Costa wrote:
> > On Tue, 2011-04-12 at 12:40 -0500, Anthony Liguori wrote:
> >> On 04/12/2011 12:23 PM, Glauber Costa wrote:
> >>> The option-rom puts all roms passed
On Tue, 2011-04-12 at 12:40 -0500, Anthony Liguori wrote:
> On 04/12/2011 12:23 PM, Glauber Costa wrote:
> > The option-rom puts all roms passed by this switch in the genroms directory,
> > through the fw_dir option. But as it turns out, not all roms should be
> > placed th
om is
initialized
before, say, gpxe, we are able to see its output in the adapter. If it is
initialized
after, we miss it.
So I believe the proper solution is to allow users to specify that a rom
belongs in vgaroms
directory instead.
Signed-off-by: Glauber Costa
CC: Gleb Natapov
---
hw/pc.c |
bootindex option was added to -option-rom switch, but never documented.
Signed-off-by: Glauber Costa
---
qemu-options.hx | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 18f54d2..96927cc 100644
--- a/qemu-options.hx
+++ b
Some roms should not live in genroms/, the default place for all roms passed
through -option-rom switch.
Rather, they'd like to be placed in vgaroms. This patch allows it to happen.
Glauber Costa (2):
document bootindex option
add fw_dir option to option-rom switch
hw/pc.c |
On Mon, 2011-04-11 at 08:47 -0500, Anthony Liguori wrote:
> On 04/11/2011 08:39 AM, Glauber Costa wrote:
> > On Mon, 2011-04-11 at 08:10 -0500, Anthony Liguori wrote:
> >> On 04/11/2011 04:08 AM, Avi Kivity wrote:
> >>> On 04/11/2011 12:06 PM, Ulrich Obergfell wrote:
On Mon, 2011-04-11 at 08:10 -0500, Anthony Liguori wrote:
> On 04/11/2011 04:08 AM, Avi Kivity wrote:
> > On 04/11/2011 12:06 PM, Ulrich Obergfell wrote:
> >> >> vmstate_hpet_timer = {
> >> >>VMSTATE_UINT64(fsb, HPETTimer),
> >> >>VMSTATE_UINT64(period, HPETTimer),
> >> >>
On Fri, 2011-04-08 at 17:54 +0200, Jan Kiszka wrote:
> > +}
>
> Did I miss some change in the plan? I thought we were heading for a
> generic, reusable driftfix tool box (or periodic timer service)? Or is
> this intentionally an intermediate step?
Which is a medium to long way in the fut
On Fri, 2011-03-18 at 11:24 +0100, Jan Kiszka wrote:
> On 2011-03-17 23:42, Glauber Costa wrote:
> > kvmclock presence can be signalled by two different flags. So for
> > device creation, we have to test for both.
> Patch is OK, but the subject's logic is inverted.
I
n represented by the break in lookup_feature.
Signed-off-by: Glauber Costa
---
target-i386/cpuid.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index d28de20..48f9bbd 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cp
kvmclock presence can be signalled by two different flags. So for
device creation, we have to test for both.
Signed-off-by: Glauber Costa
---
hw/kvmclock.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/kvmclock.c b/hw/kvmclock.c
index b6ceddf..004c4ad 100644
sm is kept for older kernels that do not
implement it.
Signed-off-by: Glauber Costa
---
target-i386/kvm.c | 76 +++-
1 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index da757fa..dc1e547 100644
This patch is a follow up to an earlier one that aims to enable
kvmclock newer msr set. This time I'm doing it through a more sane
mechanism of consulting the kernel about the supported msr set.
Glauber Costa (3):
use kernel-provided para_features instead of statically coming up
wit
>
> Signed-off-by: Jan Kiszka
> CC: Glauber Costa
> ---
> Makefile.target |4 +-
> hw/kvmclock.c | 125
> +++
> hw/kvmclock.h | 14 ++
> hw/pc_piix.c| 31 +++---
> 4 files changed, 1
On Mon, 2011-02-07 at 19:12 +0100, Jan Kiszka wrote:
> On 2011-02-07 19:04, Glauber Costa wrote:
> > On Mon, 2011-02-07 at 15:03 +0100, Jan Kiszka wrote:
> >> On 2011-02-07 14:40, Glauber Costa wrote:
> >>> On Mon, 2011-02-07 at 13:36 +0100, Jan Kiszka wrote:
>
On Mon, 2011-02-07 at 15:03 +0100, Jan Kiszka wrote:
> On 2011-02-07 14:40, Glauber Costa wrote:
> > On Mon, 2011-02-07 at 13:36 +0100, Jan Kiszka wrote:
> >> On 2011-02-07 13:27, Glauber Costa wrote:
> >>> On Mon, 2011-02-07 at 12:19 +0100, Jan Kiszka wrote:
>
On Mon, 2011-02-07 at 13:36 +0100, Jan Kiszka wrote:
> On 2011-02-07 13:27, Glauber Costa wrote:
> > On Mon, 2011-02-07 at 12:19 +0100, Jan Kiszka wrote:
> >> If kvmclock is used, which implies the kernel supports it, register a
> >> kvmclock device with the sysbus. Its
simply registering a handler for state change, and
using a per-CPUState variable that prevents double updates for the TSC.
Signed-off-by: Glauber Costa
CC: Jan Kiszka
---
v2: updated tsc validation logic, as asked by Jan
v3: regenerated against uq/master
---
target-i386/cpu.h |1 +
target
On Tue, 2011-02-01 at 21:26 +0100, Jan Kiszka wrote:
> On 2011-02-01 20:17, Glauber Costa wrote:
> > If the machine is stopped, we should not record two different tsc values
> > upon a save operation. The same problem happens with kvmclock.
> >
> > But kvmclock is
simply registering a handler for state change, and
using a per-CPUState variable that prevents double updates for the TSC.
Signed-off-by: Glauber Costa
CC: Jan Kiszka
---
v2: updated tsc validation logic, as asked by Jan
---
target-i386/cpu.h |1 +
target-i386/kvm.c | 18
simply registering a handler for state change, and
using a per-CPUState variable that prevents double updates for the TSC.
Signed-off-by: Glauber Costa
---
target-i386/cpu.h |1 +
target-i386/kvm.c | 19 ++-
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a
On Tue, 2011-01-04 at 12:45 +0100, Jan Kiszka wrote:
> Am 04.01.2011 12:43, Glauber Costa wrote:
> > On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
> >> Am 04.01.2011 12:08, Glauber Costa wrote:
> >>> On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
> Am 04.01.2011 12:08, Glauber Costa wrote:
> > On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> If kvmclock is used, which implies the kernel supports it, register a
>
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> If kvmclock is used, which implies the kernel supports it, register a
> kvmclock device with the sysbus. Its main purpose is to save and restore
> the kernel state on migration, but this will also allow to visualize it
>
ed-off-by: Jan Kiszka
> CC: Glauber Costa
looks good.
> target-i386/kvm.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index d8f26bf..8267655 100644
> --- a/target-i386/kvm.c
> +++ b/target
On Mon, 2011-01-03 at 17:46 +0100, Jan Kiszka wrote:
> Am 03.01.2011 17:40, Glauber Costa wrote:
> > On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> Make sure to clear MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK, and
> &
On Mon, 2011-01-03 at 17:30 +0100, Jan Kiszka wrote:
> Am 03.01.2011 17:04, Avi Kivity wrote:
> > On 01/03/2011 10:33 AM, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> If kvmclock is used, which implies the kernel supports it, register a
> >> kvmclock device with the sysbus. Its main purpose is
to visualize it
> one day.
>
> Signed-off-by: Jan Kiszka
> CC: Glauber Costa
Hi Jan.
I've just recently posted a patch (not sure what was made from it), that
fixes a bug that you reintroduce here.
The bug is: if we call KVM_GET_CLOCK ioctl in pre_save, this means that
this value
On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Make sure to clear MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK, and
> MSR_KVM_ASYNC_PF_EN so that a freshly booted guest cannot be disturbed
> by old values.
>
> Signed-off-by: Jan Kiszka
On Mon, 2011-01-03 at 18:04 +0200, Avi Kivity wrote:
> On 01/03/2011 10:33 AM, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > If kvmclock is used, which implies the kernel supports it, register a
> > kvmclock device with the sysbus. Its main purpose is to save and restore
> > the kernel state on mi
On Wed, 2010-12-08 at 17:31 -0200, Marcelo Tosatti wrote:
> On Tue, Dec 07, 2010 at 03:12:36PM -0200, Glauber Costa wrote:
> > On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote:
> > > On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote:
> > > > Usual
On Mon, 2010-12-06 at 19:04 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 06, 2010 at 09:03:46AM -0500, Glauber Costa wrote:
> > Usually nobody usually thinks about that scenario (me included and
> > specially),
> > but kvmclock can be actually disabled in the host.
>
patch
achives that by registering this section only if kvmclock is actually
currently enabled in cpuid.
The only caveat is that we have to register the savevm section a little bit
later, since we won't know the final kvmclock state before cpuid gets parsed.
Signed-off-by: Glauber Costa
---
c
Here, I try to register it only if it's enabled at
machine start.
v2: improvements suggested by Paolo, and patch reordering.
Glauber Costa (2):
Do not register kvmclock savevm section if kvmclock is disabled.
make kvmclock value idempotent for stopped machine
cpus.c|3
ssued more times,
but this should be fine since vm_stop is not a hot path.
When we do migrate, we'll transfer that value along.
Signed-off-by: Glauber Costa
CC: Paolo Bonzini
---
qemu-kvm-x86.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-kvm-x86.c b/qe
op
is not a hot path.
When we do migrate, we'll transfer that value along.
Signed-off-by: Glauber Costa
---
cpus.c |4
qemu-kvm-x86.c |7 ++-
qemu-kvm.h |2 ++
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/cpus.c b/cpus.c
index a55c330..879a
patch
achives that by registering this section only if kvmclock is actually
currently enabled in cpuid.
The only caveat is that we have to register the savevm section a little bit
later, since we won't know the final kvmclock state before cpuid gets parsed.
Signed-off-by: Glauber Costa
---
c
Here, I try to register it only if it's enabled at
machine start.
Thanks
Glauber Costa (2):
make kvmclock value idempotent for stopped machine
Do not register kvmclock savevm section if kvmclock is disabled.
cpus.c|7 +++
qemu-kvm-x86.c| 25 +++--
On Mon, Aug 30, 2010 at 05:35:20PM +0900, Isaku Yamahata wrote:
> On Mon, Aug 30, 2010 at 10:59:19AM +0300, Avi Kivity wrote:
> > On 08/30/2010 10:49 AM, Isaku Yamahata wrote:
> >> This patch set distinguish warm reset from cold reset by
> >> introducing warm reset callback handler.
> >> The first
> Found-by: Miguel Di Ciurcio Filho
> Signed-off-by: Alex Williamson
Acked-by: Glauber Costa
On Tue, Aug 03, 2010 at 10:19:47AM -0600, Alex Williamson wrote:
> Several devices rely on their reset() function being called to
> initialize device state, e1000 and rtl8139 in particular. When
> the device is hot added, the reset doesn't occur, often leaving
> the device in an unusable state. A
On Mon, Aug 02, 2010 at 03:15:17PM -0600, Alex Williamson wrote:
> When we hotplug the device,
> we don't go through a reset cycle, which means a hot added e1000 is
> useless until the VM reboots.
I do guess, however, that this is true for any device, right?
Wouldn't it be better to just call t
On Mon, Jun 14, 2010 at 02:58:47PM -0500, Anthony Liguori wrote:
> On 06/14/2010 02:42 PM, Glauber Costa wrote:
> >On Mon, Jun 14, 2010 at 02:33:00PM -0500, Anthony Liguori wrote:
> >>On 06/14/2010 02:27 PM, Glauber Costa wrote:
> >>>This patch fixes a bug that happe
On Tue, Jun 15, 2010 at 10:33:21AM +0300, Avi Kivity wrote:
> On 06/14/2010 10:33 PM, Anthony Liguori wrote:
> >On 06/14/2010 02:27 PM, Glauber Costa wrote:
> >>This patch fixes a bug that happens with kvm, irqchip-in-kernel,
> >>while adding a netdev. Despite the situa
On Mon, Jun 14, 2010 at 02:58:47PM -0500, Anthony Liguori wrote:
> On 06/14/2010 02:42 PM, Glauber Costa wrote:
> >On Mon, Jun 14, 2010 at 02:33:00PM -0500, Anthony Liguori wrote:
> >>On 06/14/2010 02:27 PM, Glauber Costa wrote:
> >>>This patch fixes a bug that happe
On Mon, Jun 14, 2010 at 02:33:00PM -0500, Anthony Liguori wrote:
> On 06/14/2010 02:27 PM, Glauber Costa wrote:
> >This patch fixes a bug that happens with kvm, irqchip-in-kernel,
> >while adding a netdev. Despite the situations of reproduction being
> >specific to kvm,
int on.
Making sure the vcpus are stopped before forking makes the problem go
away. Besides, this is a pretty unfrequent operation, which already hangs
the io-thread for a while. So it should not hurt performance.
Signed-off-by: Glauber Costa
---
net/tap.c |4
1 files changed, 4 inse
This patch adds initial support for the -machine option, that allows
command line specification of machine attributes.
Besides its value per-se, it is the saner way we found to
allow for enabling/disabling of kvm's in-kernel irqchip.
machine-related options like kernel, initrd, etc, are now
accept
On Wed, Jun 02, 2010 at 09:15:10AM +0200, Jan Kiszka wrote:
> >
> > +QemuOptsList qemu_machine_opts = {
> > +.name = "M",
> > +.head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head),
> > +.desc = {
> > +{
> > +.name = "mach",
> > +.type = QEMU_OPT_STRI
Hello,
This is a resent (rebased) of an old patch set of mine, I sent
some time ago. With that, we should have all the needed infrastructure
to select the in-kernel irqchip for KVM.
Glauber Costa (2):
early set current_machine
basic machine opts framework
hw/boards.h | 10
This patch adds initial support for the -machine option, that allows
command line specification of machine attributes (always relying on safe
defaults). Besides its value per-se, it is the saner way we found to
allow for enabling/disabling of kvm's in-kernel irqchip.
A machine with in-kernel-irqch
this way, the machine_init function itself can know which machine is current
in use, not only the late init code.
Signed-off-by: Glauber Costa
---
vl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 96838f8..7a8b20b 100644
--- a/vl.c
+++ b/vl.c
On Wed, Mar 24, 2010 at 02:43:35PM -0500, Anthony Liguori wrote:
> On 03/24/2010 02:26 PM, Glauber Costa wrote:
> >This patch adds initial support for the -machine option, that allows
> >command line specification of machine attributes (always relying on safe
> >defaults). Bes
this way, the machine_init function itself can know which machine is current
in use, not only the late init code.
---
vl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index d69250c..ceddeac 100644
--- a/vl.c
+++ b/vl.c
@@ -4841,6 +4841,9 @@ int main(int
nge, however: In old code, pic would always be a fallback.
Now, it will have to be explicitly selected. I believe it is better behaviour,
but this is not the most important part of it, so I can easily go back
if people want it out.
Let the flames begin!
Glauber Costa (2):
early set current_ma
This patch adds initial support for the -machine option, that allows
command line specification of machine attributes (always relying on safe
defaults). Besides its value per-se, it is the saner way we found to
allow for enabling/disabling of kvm's in-kernel irqchip.
A machine with in-kernel-irqch
On Mon, Dec 14, 2009 at 08:22:12AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
> >Well I am pretty sure that I used virtio + e1000 with 0.11
> >and apparently I can't now.
> >So it does look like a regression to me ...
>
> That's what I said, we should make sure that we stop loading
On Mon, Dec 14, 2009 at 04:11:43PM +0200, Michael S. Tsirkin wrote:
> On Mon, Dec 14, 2009 at 08:11:59AM -0600, Anthony Liguori wrote:
> > Alexander Graf wrote:
> >> Michael S. Tsirkin wrote:
> >>
> >>> On Mon, Dec 14, 2009 at 12:55:28PM +0100, Alexander Graf wrote:
> >>>
> Am 14.12.
On Mon, Dec 14, 2009 at 04:01:43PM +0200, Michael S. Tsirkin wrote:
> On Mon, Dec 14, 2009 at 02:35:31PM +0100, Alexander Graf wrote:
> > Michael S. Tsirkin wrote:
> > > On Mon, Dec 14, 2009 at 12:55:28PM +0100, Alexander Graf wrote:
> > >
> > >> Am 14.12.2009 um 11:59 schrieb "Michael S. Tsirki
that we can isolate any code that interacts
>> directly with the guest.
>
> Spice guest visible state inside qemu is just its PCI QXL device.
> This part is qemu specificed.
>
But this part can work together with vnc with no problems, right?
If this is so, why don't w
vnc-like), and
the guest device (vga-like). I am right?
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
o force them is just ridiculous.
That said, I do believe spice can play a essential role in making us go
forward, but the attitude towards it has to change quite a bit.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
?
libraries changes every single day to try to acomodate for the needs
of specific users, be it through generalizations, shims, or whatever.
This is just another day in the OSS world.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
ll will
> wakeup.
>
I don't see anthony with any specific agenda here than making qemu as best
as it can get. If he is evil, I'm the devil myself.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
do figure out the
meaning of some specific constants in the past.
+1
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
es it slightly better, tough...
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
of
> size=0 with malloc() is broken.
We can change qemu_malloc to qemu_alloc_memory(), or whatever.
But from the moment we do things like abort on failing, we are already
deviating from its C counterpart.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
On Thu, Dec 3, 2009 at 12:29 PM, Paolo Bonzini wrote:
> On 12/02/2009 02:48 PM, Glauber Costa wrote:
>>
>> + if (env == qemu_get_current_env()) {
>
> Will always be false for TCG + iothread. What's wrong with
> qemu_cpu_self(env)? It appears to do the same, and i
hing into the the machine type, we end up with
> 2^n machine types in order to control everything.
I am totally fine re-including the cmdline patch in the series.
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
On Thu, Dec 3, 2009 at 10:37 AM, Avi Kivity wrote:
> On 12/03/2009 02:36 PM, Glauber Costa wrote:
>>
>> On Thu, Dec 3, 2009 at 10:23 AM, Avi Kivity wrote:
>>
>>>
>>> On 12/02/2009 03:48 PM, Glauber Costa wrote:
>>>
>>>>
>>&
;>>
>>
>> to keep gdbstub working.
>>
>
> "Because it fixes things".
>
> Please elaborate.
>
gdbstub is called from the i/o thread , and call vcpu ioctls. So it
has to use the on_vcpu
mechanism to guarantee its execution in the right thread.
What I meant is that currently, gdbstub is the only user of it, at
least in qemu.git
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
On Thu, Dec 3, 2009 at 10:23 AM, Avi Kivity wrote:
> On 12/02/2009 03:48 PM, Glauber Costa wrote:
>>
>> We don't support smp without irqchip in kernel, so only abort in
>> that situation
>>
>
>
> What's the reason for this restriction?
It is temp
On Thu, Dec 3, 2009 at 10:20 AM, Avi Kivity wrote:
> On 12/02/2009 03:48 PM, Glauber Costa wrote:
>>
>> This function is similar to qemu-kvm's on_vcpu mechanism.
>
> Is similar? You're replacing on_vcpu().
Yeah, it began similar, now it is pretty much the same thin
ype that does not do irqchip in
kernel, if wanted.
However, since it is probably not going to reach 0.12 anyway, we can
come up with a patch
that fixes msix, and bundle in this series before I actually enable
the irqchip (which is one
of the last patches)
--
Glauber Costa.
"Free as in Fr
>
> Does msix work with this patchset when in-kernel irqchip
> is enabled?
Haven't tested. But since I see that msix need some special code in qemu-kvm,
it probably won't. But I assume we can just add a patch ontop of this to add
that code and make it work, right?
--
Glauber
On Wed, Dec 02, 2009 at 11:54:45AM -0200, Marcelo Tosatti wrote:
> On Wed, Dec 02, 2009 at 11:41:19AM -0200, Glauber Costa wrote:
> > > KVM vcpu threads should block SIGUSR1, set the in-kernel signal mask
> > > with KVM_SET_SIGNAL_MASK ioctl, and eat the signal in
>
It is much faster than pthread_{g,s}et_specific.
Signed-off-by: Glauber Costa
---
configure | 17 +
vl.c | 16
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index dca5a43..ce7bcc4 100755
--- a/configure
+++ b
We don't support smp without irqchip in kernel, so only abort in
that situation
Signed-off-by: Glauber Costa
---
kvm-all.c | 10 +-
kvm.h |2 ++
target-i386/kvm.c |7 +++
target-ppc/kvm.c |5 +
4 files changed, 19 insertions(+), 5 dele
: Glauber Costa
---
cpu-defs.h|2 ++
exec-all.h| 12
exec.c| 32
hw/apic-kvm.c | 16
kvm-all.c |7 +++
vl.c | 10 ++
6 files changed, 67 insertions(+), 12 deletions(-)
diff --git
This have already been identified in qemu-kvm. We have to synchronously
tell the kernel about the APIC state. Otherwise, other cpus can see
bogus state for this lapic.
Signed-off-by: Glauber Costa
---
hw/apic-kvm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw
All reset functions are called from the same place, and this was a leftover
Signed-off-by: Glauber Costa
---
kvm-all.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 596416a..1072d63 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -204,8 +204,6
Before signalling a cpu, we have to set exit_request = 1, otherwise
it may go back to executing itself. So every cpu wakeup becomes
at least two statements. The qemu_cpu_kick already provides semantics
to that. So use it all over.
Signed-off-by: Glauber Costa
---
vl.c |6 +++---
1 files
the cpu's APIC, other cpus can still see an invalid state.
Since putting registers already happen in vcpu entry, we factor
out the required code in cpu_flush_state()
Signed-off-by: Glauber Costa
---
hw/apic-kvm.c |5 -
kvm-all.c | 13 +
kvm.h |8 ++
If we are using in-kernel irqchip, halted state belongs in the kernel.
So everytime we grab kernel's idea of mpstate, we also need to propagate
halted state to userspace.
Signed-off-by: Glauber Costa
---
target-i386/kvm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
This function is similar to qemu-kvm's on_vcpu mechanism. Totally synchronous,
and guarantees that a given function will be executed at the specified vcpu.
This patch also convert usage within the breakpoints system
Signed-off-by: Glauber Costa
---
cpu-all.h |3 ++
cpu-defs.h |
When we have irqchip in kernel, halted state is kernel
business. So don't initialize it in our code.
Signed-off-by: Glauber Costa
---
hw/apic-kvm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/apic-kvm.c b/hw/apic-kvm.c
index 089fa45..e5a0bfc 100644
---
igned-off-by: Glauber Costa
---
vl.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index 44763af..321b18d 100644
--- a/vl.c
+++ b/vl.c
@@ -3434,6 +3434,24 @@ static void block_io_signals(void);
static void unblock_io_signals(void);
s
Avi/Marcelo
Please include this in a branch in qemu-kvm for future inclusion
in qemu.git. It is the same material people have already commented
on in the ML.
Glauber Costa (11):
Don't mess with halted state.
store thread-specific env information
update halted state on mp_state
1 - 100 of 208 matches
Mail list logo
