On 03/13/2012 08:44 AM, Wen Congyang wrote:
> At 03/12/2012 06:33 PM, Avi Kivity Wrote:
> > On 03/12/2012 11:04 AM, Wen Congyang wrote:
> >> Do you have any other comments about this patch?
> >>
> >
> > Not really, but I'm not 100% convinced the patc
On 03/13/2012 11:18 AM, Daniel P. Berrange wrote:
> On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote:
> > On 03/12/2012 11:04 AM, Wen Congyang wrote:
> > > Do you have any other comments about this patch?
> > >
> >
> > Not really, but I'
On 03/12/2012 08:18 PM, Stefano Stabellini wrote:
> >
> > * Reviewed-by: Full Name
> >
> > A Reviewed-by tag is a statement of opinion that the patch is an
> > appropriate
> > modification without any remaining serious technical issues. Any
> > interested
> > reviewer (who has done the w
On 03/12/2012 10:27 PM, Anthony Liguori wrote:
>> I agree that more maintainers would be good, but we also need
>> more people with commit rights.
>
> I disagree strongly. Having multiple pushers makes things difficult
> and encourages people to push without testing. Part of what makes
> pushing
On 03/13/2012 11:09 AM, Peter Maydell wrote:
> > If we start saying that, Alex "owns" ppc except for things that are
> > "important" like a build breakage, then we get into the ugly definition of
> > what's important and what's not important.
>
> I don't think we've had huge problems with defining
On 03/13/2012 04:00 PM, Anthony Liguori wrote:
> On 03/13/2012 08:40 AM, Avi Kivity wrote:
>> On 03/12/2012 10:27 PM, Anthony Liguori wrote:
>>>> I agree that more maintainers would be good, but we also need
>>>> more people with commit rights.
>>>
>>
On 03/13/2012 04:12 PM, Peter Maydell wrote:
> >> (plus it puts an extra person in the loop which is pretty
> >> much guaranteed to slow things down).
> >
> > Having the committers process all these patches (and monitor all
> > patches) is guaranteed to slow things down too.
>
> They're in the loop
On 03/13/2012 04:49 PM, Andreas Färber wrote:
> >
> > Not at all. I have a memory/core branch and a memory/urgent branch --
> > it's trivial to maintain them with git, and quite often I send a 1-patch
> > pull request. There's no material difference between sending a patch
> > and sending a pull
On 03/13/2012 12:42 PM, Amos Kong wrote:
> Boot up guest with 232 virtio-blk disk, qemu will abort for fail to
> allocate ioeventfd. This patchset changes kvm_has_many_ioeventfds(),
> and check if available ioeventfd exists. If not, virtio-pci will
> fallback to userspace, and don't use ioeventfd f
On 03/14/2012 10:29 AM, Wen Congyang wrote:
> At 03/13/2012 06:47 PM, Avi Kivity Wrote:
> > On 03/13/2012 11:18 AM, Daniel P. Berrange wrote:
> >> On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote:
> >>> On 03/12/2012 11:04 AM, Wen Congyang wrote:
> &g
On 03/14/2012 11:59 AM, Stefan Hajnoczi wrote:
> On Wed, Mar 14, 2012 at 9:22 AM, Avi Kivity wrote:
> > On 03/13/2012 12:42 PM, Amos Kong wrote:
> >> Boot up guest with 232 virtio-blk disk, qemu will abort for fail to
> >> allocate ioeventfd. This patchset chan
On 03/14/2012 11:53 AM, Wen Congyang wrote:
> At 03/14/2012 05:24 PM, Avi Kivity Wrote:
> > On 03/14/2012 10:29 AM, Wen Congyang wrote:
> >> At 03/13/2012 06:47 PM, Avi Kivity Wrote:
> >>> On 03/13/2012 11:18 AM, Daniel P. Berrange wrote:
> >>>> On Mon,
On 03/14/2012 12:04 PM, Wen Congyang wrote:
> >
> > This is sufficient. On the host, you can open /tmp/foo using a custom
> > program or nc (nc -U /tmp/foo). On the guest, you can just open
> > /dev/virtio-ports/port1 and read/write into it.
>
> I have two questions:
> 1. does it OK to open this
On 03/12/2012 11:43 AM, Igor Mitsyanko wrote:
> On 02/21/2012 07:33 PM, Peter Maydell wrote:
>>
>> Short summary:
>> * switch wp groups to bitfield rather than int array
>> * convert sd.c to use memory_region_init_ram() to allocate the wp
>> groups
>> (being careful to use memory_region_set_dir
On 03/14/2012 12:26 PM, Wen Congyang wrote:
> >> If so, is this channel visible to guest userspace? If the channle is
> >> visible to guest
> >> userspace, the program running in userspace may write the same message to
> >> the channel.
> >>
> >
> > Surely there's some kind of access control on
On 03/14/2012 12:39 PM, Stefan Hajnoczi wrote:
> On Wed, Mar 14, 2012 at 10:05 AM, Avi Kivity wrote:
> > On 03/14/2012 11:59 AM, Stefan Hajnoczi wrote:
> >> On Wed, Mar 14, 2012 at 9:22 AM, Avi Kivity wrote:
> >> > On 03/13/2012 12:42 PM, Amos Kong wrote:
> &g
On 03/14/2012 12:46 PM, Gleb Natapov wrote:
> On Wed, Mar 14, 2012 at 12:29:57PM +0200, Avi Kivity wrote:
> > On 03/14/2012 12:26 PM, Wen Congyang wrote:
> > > >> If so, is this channel visible to guest userspace? If the channle is
> > > >> visible to guest
On 03/14/2012 12:52 PM, Wen Congyang wrote:
> >
> >> If so, is this channel visible to guest userspace? If the channle is
> >> visible to guest
> >> userspace, the program running in userspace may write the same message to
> >> the channel.
> >
> > Access control is via permissions. You can ha
On 03/14/2012 01:11 PM, Wen Congyang wrote:
> >
> > I don't think we want to use the driver. Instead, have a small piece of
> > code that resets the device and pushes out a string (the panic message?)
> > without any interrupts etc.
> >
> > It's still going to be less reliable than a hypercall,
On 03/14/2012 03:07 PM, Avi Kivity wrote:
> On 03/14/2012 01:11 PM, Wen Congyang wrote:
> > >
> > > I don't think we want to use the driver. Instead, have a small piece of
> > > code that resets the device and pushes out a string (the panic message
On 03/14/2012 03:14 PM, Gleb Natapov wrote:
> On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote:
> > On 03/14/2012 01:11 PM, Wen Congyang wrote:
> > > >
> > > > I don't think we want to use the driver. Instead, have a small piece of
> > >
On 03/14/2012 10:33 PM, Anthony Liguori wrote:
> On 03/06/2012 09:50 AM, Avi Kivity wrote:
>> The kvmvapic code remaps a section of ROM as RAM to allow the guest to
>> maintain state there. It is careful to align the section size to a page
>> boundary, to avoid creating subp
On 03/15/2012 01:25 PM, Jan Kiszka wrote:
> >>
> > There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a
> > bad idea.
>
> BTW, this would help a lot in emulating hypercalls of other hypervisors
> (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump
> through hoop
On 03/15/2012 01:47 PM, Stefan Hajnoczi wrote:
> On Thu, Mar 15, 2012 at 9:02 AM, Dmitry Fleytman
> wrote:
> > Below is the implementation of VMWare PVSCSI device and
> > command line parameters to configure vendor name and product name
> > for SCSI storage are implemented.
> > Latter is needed to
On 03/15/2012 04:30 PM, Alexey Starikovskiy wrote:
> Sufficient to boot Linux kernel on vexpress-a15
>
> Missing:
> * Extends the DBGDRAR and DBGDSAR to 64 bits, to hold PAs of up to 40 bits.
> * Defines two Memory Attribute Indirection Registers, MAIRn, to replace PRRR
> and NMRR when
> using the
On 03/15/2012 05:24 PM, Peter Maydell wrote:
> On 15 March 2012 15:20, Avi Kivity wrote:
> > Please add code that detects the use of unimplemented features and
> > aborts
>
> I'm not a great fan of letting the guest cause QEMU to abort...
Why not? It (the guest) is g
On 03/15/2012 05:37 PM, Peter Maydell wrote:
> On 15 March 2012 15:31, Avi Kivity wrote:
> > On 03/15/2012 05:24 PM, Peter Maydell wrote:
> >> On 15 March 2012 15:20, Avi Kivity wrote:
> >> > Please add code that detects the use of unimplemented features and
>
On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
> Hi Avi/Blue,
>
> I've just updated to git master and found that SPARC64 is broken
> again; a git bisect shows the following commit causes this:
>
>
> commit f3705d53296d78b14f5823472ae2add16a25a0a5
> Author: Avi Kivity
about to unhappen, so fix the code to use an iotlb entry (using the
>> code entry with TLB_MMIO may fail if the page is a watchpoint).
>>
>> Signed-off-by: Avi Kivity
>> ---
>> exec.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
&
On 03/18/2012 11:51 AM, Blue Swirl wrote:
> On Sun, Mar 18, 2012 at 09:44, Avi Kivity wrote:
> > On 03/18/2012 04:01 AM, Mark Cave-Ayland wrote:
> >> Hi Avi/Blue,
> >>
> >> I've just updated to git master and found that SPARC64 is broken
> >> aga
On 03/18/2012 12:51 PM, Blue Swirl wrote:
> >
> > IMO, my patch is better. tlb_set_page() should not deal with offsets
> > within a page.
>
> It looks like all targets except Sparc32/64 mask the addresses before
> passing to tlb_set_page(), so I agree.
Ok. Commit my patch then?
> > If you prefe
On 03/18/2012 02:10 PM, Blue Swirl wrote:
> On Sun, Mar 18, 2012 at 12:08, Avi Kivity wrote:
> > On 03/18/2012 12:51 PM, Blue Swirl wrote:
> >> >
> >> > IMO, my patch is better. tlb_set_page() should not deal with offsets
> >> > within a page.
>
a live instance.
Signed-off-by: Avi Kivity
---
scripts/qemu-gdb.py | 89 +++
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644 scripts/qemu-gdb.py
diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py
new file mode 1006
On 03/18/2012 02:08 PM, Avi Kivity wrote:
> >
> > Screen is not updated correctly, there are lines from previous
> > screenful. Pressing ctrl-alt-1 refreshes the display. Perhaps dirty
> > tracking is broken? VGA in x86 works.
>
> Ok, I see it. Will investigate.
>
Also, try the attached patch.
--
error compiling committee.c: too many arguments to function
>From bb363db2608dfc9b49b53994dc20d68169e66774 Mon Sep 17 00:00:00 2001
From: Avi Kivity
Date: Wed, 14 Mar 2012 16:19:39 +0200
Subject: [PATCH] exec: fix write tlb entry misused as iotlb
A couple of
ident is
> >>> about to unhappen, so fix the code to use an iotlb entry (using the
> >>> code entry with TLB_MMIO may fail if the page is a watchpoint).
> >>>
> >>> Signed-off-by: Avi Kivity
> >>> ---
> >>> exec.c |2 +-
&
On 03/19/2012 06:52 AM, TeLeMan wrote:
> > static bool memory_region_wrong_endianness(MemoryRegion *mr)
> > @@ -942,7 +940,7 @@ void memory_region_init_io(MemoryRegion *mr,
> > mr->opaque = opaque;
> > mr->terminates = true;
> > mr->destructor = memory_region_destructor_iomem;
> > -
The last memory core pull introduced a couple of regressions; here are
the fixes.
Please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/urgent
Avi Kivity (2):
exec: fix write tlb entry misused as
On 03/19/2012 06:34 AM, Roy Tam wrote:
> But I get "*** stack smashing detected ***: terminated" and crash
> when booting BeOS 5.
>
Is that a regression? From what commit?
--
error compiling committee.c: too many arguments to function
On 03/16/2012 10:59 AM, Amos Kong wrote:
>
> Can you give some detail about this? I'm not familiar with Memory API.
Well there's a huge amount of detail needed here. The idea is that
memory_region_add_eventfd() will always work, with or without kvm, and
even if kvm is enabled but we run out of io
On 03/19/2012 12:37 PM, TeLeMan wrote:
> On Mon, Mar 19, 2012 at 17:16, Avi Kivity wrote:
> > On 03/19/2012 06:52 AM, TeLeMan wrote:
> >> > static bool memory_region_wrong_endianness(MemoryRegion *mr)
> >> > @@ -942,7 +940,7 @@ void memory_region_init_io(Memory
On 03/19/2012 08:14 AM, Zhang, Yang Z wrote:
> The new logic is compatible with old. So it should not block migrate from old
> version. But new version cannot migrate to old.
>
> +static int rtc_load_old(QEMUFile *f, void *opaque, int version_id)
> +{
> +RTCState *s = opaque;
> +
> +if (ve
void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v)
{
if (env->sregs[IBREAKENABLE] & (1 << i) && env->sregs[IBREAKA + i]
!= v) {
tb_invalidate_phys_page_range(
env->sregs[IBREAKA + i], env->sregs[IBREAKA + i] + 1, 0);
tb_invalidate_phys_page_range(v, v + 1, 0);
On 03/18/2012 02:05 PM, Blue Swirl wrote:
> Print also I/O ports behind bridges and other aliases.
>
Thanks, both applied.
--
error compiling committee.c: too many arguments to function
On 03/19/2012 03:51 PM, Max Filippov wrote:
> > void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v)
> > {
> >if (env->sregs[IBREAKENABLE] & (1 << i) && env->sregs[IBREAKA + i]
> > != v) {
> >tb_invalidate_phys_page_range(
> >env->sregs[IBREAKA + i], env->sregs[IBREAKA + i]
On 03/19/2012 05:54 PM, Anthony PERARD wrote:
> In cpu_physical_memory_rw, a change has been introduced and qemu_get_ram_ptr
> is
> no longuer called with the ram addr we want to access, but only with the
> section address. This patch fixes this. (All other call to qemu_get_ram_ptr
> are
> alread
On 03/19/2012 11:40 AM, Avi Kivity wrote:
> The last memory core pull introduced a couple of regressions; here are
> the fixes.
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/urgent
>
I've tacked on another patch to this branc
On 03/19/2012 05:56 PM, Michael S. Tsirkin wrote:
> Currently virtio-pci is specified so that configuration of the device is
> done through a PCI IO space (via BAR 0 of the virtual PCI device).
> However, Linux guests happen to use ioread/iowrite/iomap primitives
> for access, and these work unifor
On 03/19/2012 08:57 PM, Michael S. Tsirkin wrote:
> >
> > Should be done via an extra BAR (with the same layout, perhaps extended)
> > so compatibility is preserved.
>
> No, that would need guest changes to be of use. The point of this hack
> is to make things work for Linux guests where PIO does
On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> This is now implied by kvm_irqchip_in_kernel.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> This is now implied by kvm_irqchip_in_kernel.
>
>
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
--
error compiling committee.c: too many arguments to function
On 03/21/2012 03:40 PM, Jan Kiszka wrote:
> On 2012-03-21 13:38, GaoYi wrote:
> > Hi Jan,
> >
> > Since the newest Intel-VT supports the guest OS under the real mode,
> > which was already supported in AMD-V, can the VMX in the latest KVM support
> > that case?
>
> Yes, both with our without
On 03/21/2012 06:18 PM, Corey Minyard wrote:
>
>> Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic
>> event over IMPI. The code is pretty complex. Of course if we a going to
>> implement something more complex than simple hypercall for panic
>> notification we better do someth
On 03/21/2012 07:04 PM, Daniel P. Berrange wrote:
> >
> > In fact the feature can be implemented 100% host side by searching for a
> > panic string signature in the console logs.
>
> You can even go one better and search for the panic string in the
> guest memory directly, which is what virt-dmesg
On 03/22/2012 03:28 PM, Jan Kiszka wrote:
> On 2012-03-20 13:31, Michael S. Tsirkin wrote:
> > We use a 2 byte ioeventfd for virtio memory,
> > add support for this.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > hw/ivshmem.c |8
> > kvm-all.c| 15 ---
> > k
On 03/20/2012 02:31 PM, Michael S. Tsirkin wrote:
> We use a 2 byte ioeventfd for virtio memory,
> add support for this.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
On 03/25/2012 04:00 AM, Max Filippov wrote:
>>
>> Since I'm rewriting this area, don't worry about efficiency. Let's get
>> it correct and after the rewrite we can reexamine efficiency.
>>
>> I imagine you'll need something like breakpoint_invalidate().
>
> The following RFC patch takes the obviou
On 03/23/2012 07:58 PM, Luiz Capitulino wrote:
> On Wed, 21 Mar 2012 15:48:43 +0200
> Avi Kivity wrote:
>
> > On 03/21/2012 03:40 PM, Jan Kiszka wrote:
> > > On 2012-03-21 13:38, GaoYi wrote:
> > > > Hi Jan,
> > > >
> > > > Si
On 03/23/2012 06:37 PM, Jan Kiszka wrote:
> On 2012-03-23 16:08, Julien Grall wrote:
> > On 03/22/2012 05:44 PM, Jan Kiszka wrote:
> >>>
> >>> static void core_region_nop(MemoryListener *listener,
> >>> diff --git a/ioport.c b/ioport.c
> >>> index 78a3b89..073ed75 100644
> >>> --- a/ioport.c
> >>
On 03/23/2012 01:02 PM, Stefano Stabellini wrote:
> Maybe the best thing to do is to have a set of machine specific options
> to select what devices need to be built in the machine.
> Most devices already can be dynamically selected: NICs, usb, acpi,
> cirrus, etc.
> We already have a Xen machine (
On 03/25/2012 02:55 PM, Anthony Liguori wrote:
>> If cpu models are not part of configuration they should not be affected
>> by configuration mechanism. You are just avoiding addressing the real
>> question that if asked above.
>
>
> I think you're just refusing to listen.
>
> The stated direction
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
>>> qemu -M pc
>>>
>>> Would effectively be short hand for -readconfig
>>> /usr/share/qemu/machines/pc.cfg
>>
>> In that case
>>
>> qemu -cpu westmere
>>
>> is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
>
>
> This is not a bad sugge
On 03/11/2012 04:12 PM, Anthony Liguori wrote:
>> Let me elaborate about the later. Suppose host CPU has kill_guest
>> feature and at the time a guest was installed it was not implemented by
>> kvm. Since it was not implemented by kvm it was not present in vcpu
>> during installation and the guest
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
>>>
>>>
>>> This is not a bad suggestion, although it would make -cpu ? a bit
>>> awkward. Do you see an advantage to this over
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
>> Apart from the command line length, it confuses configuration with
>> definition.
>
>
> There is no distinction with what we have today. Our configuration
> file basically corresponds to command line options and as there is no
> distinction in comm
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
> On 03/25/2012 09:46 AM, Avi Kivity wrote:
>> On 03/25/2012 04:36 PM, Anthony Liguori wrote:
>>>> Apart from the command line length, it confuses configuration with
>>>> definition.
>>>
>>>
>&g
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
>> As log as qemu -nodefconfig -cpu westmere -M pc1.1
>
>
> -nodefconfig is going to eventually mean that -cpu westmere and -M
> pc-1.1 will not work.
>
> This is where QEMU is going. There is no reason that a normal user
> should ever use -nodefconfi
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
>> Put the emphasis around *configuration*.
>
>
> So how about:
>
> 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
> '@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
> '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
>
> 2) system-@ARCH@.cfg will contain:
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
> On 03/25/2012 10:18 AM, Avi Kivity wrote:
>> On 03/25/2012 05:07 PM, Anthony Liguori wrote:
>>>> As log as qemu -nodefconfig -cpu westmere -M pc1.1
>>>
>>>
>>> -nodefconfig is going to eventually me
On 03/25/2012 03:26 PM, Anthony Liguori wrote:
>>> We would continue to have Westmere/etc in QEMU exposed as part of the
>>> user configuration. But I don't think it makes a lot of sense to have
>>> to modify QEMU any time a new CPU comes out.
>>
>> We have to. New features often come with new MS
On 03/25/2012 08:01 PM, Anthony Liguori wrote:
>> I don't think this came out of happiness, but despair. Seriously,
>> keeping compatibility is one of the things we work hardest to achieve,
>> and we can't manage it for our command line?
>
>
> I hate to burst your bubble, but we struggle and rarel
On 03/25/2012 08:11 PM, Anthony Liguori wrote:
>
>> I don't think -nodefconfig (as defined) is usable, since there is no way
>> for the user to tell what it means short of reading those files.
>
> *if the user doesn't know specifics about this QEMU version.
>
> You make the assumption that all user
On 03/26/2012 11:48 AM, Michael S. Tsirkin wrote:
> kvm used to carry this commit:
Used to? Which commit reverts this?
> commit 4667e6ec0df770867095d8093562d93c94d96ca2
> Author: Avi Kivity
> Date: Thu Feb 12 11:43:17 2009 +0200
>
> Change virtio-console t
On 03/26/2012 01:01 PM, Stefano Stabellini wrote:
> On Sun, 25 Mar 2012, Avi Kivity wrote:
> > On 03/23/2012 06:37 PM, Jan Kiszka wrote:
> > > On 2012-03-23 16:08, Julien Grall wrote:
> > > > On 03/22/2012 05:44 PM, Jan Kiszka wrote:
> > > >>>
> &
On 03/26/2012 01:45 PM, Stefano Stabellini wrote:
> > >
> > >
> > > Now the problem is: there isn't a simple way to specify the BDF where
> > > you want to create the device; pci_create_simple takes a devfn but most
> > > of the higher level functions (pc_vga_init, pci_nic_init_nofail, ...)
> > > d
On 03/26/2012 01:24 PM, Jiri Denemark wrote:
> ...
> > > The command line becomes unstable if you use -nodefconfig.
> >
> > -no-user-config solves this but I fully expect libvirt would continue to
> > use
> > -nodefconfig.
>
> Libvirt uses -nodefaults -nodefconfig because it wants to fully contr
On 03/26/2012 01:19 PM, Michael S. Tsirkin wrote:
> On Mon, Mar 26, 2012 at 12:18:54PM +0200, Avi Kivity wrote:
> > On 03/26/2012 11:48 AM, Michael S. Tsirkin wrote:
> > > kvm used to carry this commit:
> >
> > Used to? Which commit reverts this?
>
> A merg
On 03/26/2012 02:20 PM, Stefano Stabellini wrote:
> On Mon, 26 Mar 2012, Avi Kivity wrote:
> > > > You may want your own host/pci bridge that lacks the device 0
> > > > configuration space.
> > >
> > > In order not to disrupt the emulated machine in QE
On 03/26/2012 04:06 AM, Wanpeng Li wrote:
> From: Anthony Liguori
>
> @@ -889,7 +900,7 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
> DeviceState *dev;
> static int apic_mapped;
>
> -if (kvm_irqchip_in_kernel()) {
> +if (kvm_enabled() && kvm_irqchip_in_kernel())
On 03/26/2012 11:40 AM, Michael S. Tsirkin wrote:
> Make it easier to add compat properties, by
> adding macros for properties duplicated across
> machine types.
>
> Note: there could be bugs in compat properties,
> this patch does not attempt to address them,
> the code is bug for bug identical to
On 03/26/2012 01:24 PM, Julien Grall wrote:
>>> It looks like there are quite a few register_ioport_read/write left
>>> around, especially in the following files:
>>>
>>> hw/acpi_piix4.c
>>> hw/cirrus_vga.c
>>> hw/serial.c
>>> hw/pckbd.c
>>> hw/pc.c
>>>
>>> I guess they should all be converted to m
On 03/26/2012 03:37 PM, Michael S. Tsirkin wrote:
> Exactly. qemu-kvm used to set the class to CLASS_OTHER while
> the current code sets it to PCI_CLASS_COMMUNICATION_OTHER.
> Do we want support for CLASS_OTHER or is it ok to drop it?
>
>
Looks like starting with qemu-kvm-0.11, qemu-kvm matches qe
On 03/26/2012 07:29 PM, Anthony Liguori wrote:
> On 03/26/2012 10:54 AM, Isaku Yamahata wrote:
>> On Mon, Mar 26, 2012 at 02:20:24PM +0200, Jan Kiszka wrote:
>>> I'm also sure we will have to refactor the merge significantly again
>>> for
>>> the introduction of additional chipsets and PC boards. B
he timers before trying to rearm the timer, we always rearm
> with a non-zero deadline, effectively halving the number of system calls.
Reviewed-by: Avi Kivity
Note the canonical subject line for patches is "subsystem: short
description", in this case something like "qemu-
On 03/27/2012 03:52 PM, Anthony Liguori wrote:
> On 03/27/2012 05:31 AM, Avi Kivity wrote:
>>>
>>> I think the better approach is to have a PCNorthBridge base-class that
>>> contains functionality like PAM/SRAM that both I440FX and Q35 inherit
>>> from
On 03/27/2012 11:55 AM, Jan Kiszka wrote:
> On 2012-03-27 10:55, Vasilis Liaskovitis wrote:
> > Hi,
> >
> > is live migration between qemu-kvm stable-0.15 and stable-1.0 trees
> > possible?
> > When I live migrate a VM from 1.0 to 0.15, the destination side 0.15
> > qemu-kvm
> > exits with:
> >
On 03/27/2012 06:39 PM, Anthony Liguori wrote:
>
> So, since we're approaching 1.1, we should really discuss release
> criteria for 1.1 with respect to live migration. I'd prefer to avoid
> surprises in this release.
Agree strongly.
>
> My expectation is that migration works from:
>
> qemu-1.0 -
On 03/26/2012 09:03 PM, Anthony Liguori wrote:
>
> I think what we want to move toward is a -no-machine option which
> allows a user to explicitly build a machine from scratch. That is:
>
> qemu -no-machine -device i440fx,id=host -device isa-serial,chr=chr0 ...
>
I'd call it -M bare-1.1, so that
On 03/26/2012 09:00 PM, Anthony Liguori wrote:
>>> Yes, that's one reason. But maybe a user wants to have a whole
>>> different set of machine types and doesn't care to have the ones we
>>> provide. Why prevent a user from doing this?
>>
>> How are we preventing a user from doing it? In what way
On 03/22/2012 01:17 AM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> This patch basically adds kvm_irqchip_send_msi, a service for sending
> arbitrary MSI messages to KVM's in-kernel irqchip models.
>
> As the current KVI API requires us to establish a static route from a
s/KVI/KVM/
> pseudo GSI to
On 03/28/2012 01:33 PM, Jan Kiszka wrote:
> On 2012-03-28 13:09, Avi Kivity wrote:
> > On 03/22/2012 01:17 AM, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> This patch basically adds kvm_irqchip_send_msi, a service for sending
> >> arbitrary M
On 03/28/2012 01:54 PM, Jan Kiszka wrote:
> >
> >>>
> interface transparent. We create those routes on demand and keep them
> in a hash table. Succeeding messages can then search for an existing
> route in the table first and reuse it whenever possible. If we should
> run out o
On 03/29/2012 01:56 PM, Jan Kiszka wrote:
> On 2012-03-27 18:39, Anthony Liguori wrote:
> > On 03/27/2012 11:22 AM, Jan Kiszka wrote:
> >> On 2012-03-27 17:59, Avi Kivity wrote:
> >>> On 03/27/2012 11:55 AM, Jan Kiszka wrote:
> >>>> On 2012-03-27
On 03/29/2012 05:21 PM, Anthony Liguori wrote:
>> Option 1: make -M old force an old vmstate to be written out. Sounds
>> like a generally useful thing.
>> Option 2: ask those consumers to issue updates that bring their code up
>> to version 3. Require fully updated qemus on both sides. Easy to
The current memory APIs (cpu_register_io_memory,
cpu_register_physical_memory) suffer from a number of drawbacks:
- lack of centralized bookkeeping
- a cpu_register_physical_memory() that overlaps an existing region
will overwrite the preexisting region; but a following
cpu_unregister_physi
On 05/18/2011 05:05 PM, Jan Kiszka wrote:
On 2011-05-18 15:12, Avi Kivity wrote:
> The current memory APIs (cpu_register_io_memory,
> cpu_register_physical_memory) suffer from a number of drawbacks:
>
> - lack of centralized bookkeeping
> - a cpu_register_physical_memory(
On 05/18/2011 06:11 PM, Jan Kiszka wrote:
On 2011-05-18 16:36, Avi Kivity wrote:
>> I would add another drawback:
>>
>>- Inability to identify the origin of a region accesses and handle them
>> differently based on the source.
>>
>> That is a
On 05/18/2011 06:14 PM, Anthony Liguori wrote:
On 05/18/2011 09:05 AM, Jan Kiszka wrote:
On 2011-05-18 15:12, Avi Kivity wrote:
The current memory APIs (cpu_register_io_memory,
cpu_register_physical_memory) suffer from a number of drawbacks:
- lack of centralized bookkeeping
- a
On 05/18/2011 06:08 PM, Anthony Liguori wrote:
On 05/18/2011 08:12 AM, Avi Kivity wrote:
The current memory APIs (cpu_register_io_memory,
cpu_register_physical_memory) suffer from a number of drawbacks:
- lack of centralized bookkeeping
- a cpu_register_physical_memory() that overlaps an
On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>
> We need to head for the more hardware-like approach. What happens when
> you program overlapping BARs? I imagine the result is
> implementation-defined, but ends up with one region decoded in
> preference to the other. There is simply no way to
801 - 900 of 4803 matches
Mail list logo
