On 08/04/2012 07:58 AM, Jamie Heilman wrote:
> Avi Kivity wrote:
>> On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
>> > On Wed, 25 Jul 2012, Michael Tokarev wrote:
>> >> Stefano, Paul, can you take a look please?
>> >>
>> >> https://bug
On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
> But still i got the segfault and core dump - this is my main problem? I
> mean qemu-kvm master isn't declared as stable. So i don't care about the
> slowness here.
>
> What can we do about the core dump and crash?
Okay, I reproduced i
On 08/06/2012 03:12 PM, Avi Kivity wrote:
> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>
>> But still i got the segfault and core dump - this is my main problem? I
>> mean qemu-kvm master isn't declared as stable. So i don't care about the
>> sl
On 08/06/2012 03:37 PM, Avi Kivity wrote:
> On 08/06/2012 03:12 PM, Avi Kivity wrote:
>> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>>
>>> But still i got the segfault and core dump - this is my main problem? I
>>> mean qemu-kvm master isn'
The scsi passthrough handler falls through after completing a
request into the failure path, resulting in a use after free.
Reprducible by running a guest with aio=native on a block device.
Reported-by: Stefan Priebe
Signed-off-by: Avi Kivity
---
hw/virtio-blk.c | 1 +
1 file changed, 1
On 08/06/2012 04:11 PM, Stefan Hajnoczi wrote:
> On Mon, Aug 6, 2012 at 1:49 PM, Avi Kivity wrote:
>> The scsi passthrough handler falls through after completing a
>> request into the failure path, resulting in a use after free.
>>
>> Reprducible by running a guest
On 08/01/2012 07:05 AM, David Gibson wrote:
> From: Alexey Kardashevskiy
>
> QEMU uses IO handlers to run select() in the main loop.
> The handlers list is managed by qemu_set_fd_handler() helper
> which works fine when called from the main thread as it is
> called when select() is not waiting.
>
On 08/06/2012 06:40 PM, Bhushan Bharat-R65777 wrote:
> Hi Avi/All,
>
> I am facing issue to boot KVM guest on x86 (I used to work on PowerPC
> platform and do not have enough knowledge of x86). I am working on making
> VFIO working on PowerPC Booke, So I have cloned Alex Williamsons git
> repos
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> If out of global lock, we will be challenged by SMP in low level,
> so need atomic ops.
>
> This file is heavily copied from kernel. Currently, only x86 atomic ops
> included, and will be extended for other arch for future.
>
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Collect unused object and release them at caller demand.
>
Please explain the motivation for this patch.
--
error compiling committee.c: too many arguments to function
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Using mem_map_lock to protect among updaters. So we can get the intact
> snapshot of mem topology -- FlatView & radix-tree.
>
> Signed-off-by: Liu Ping Fan
> ---
> exec.c |3 +++
> memory.c | 22 ++
On 08/08/2012 12:07 PM, Paolo Bonzini wrote:
> Il 08/08/2012 11:05, Avi Kivity ha scritto:
>>> > From: Liu Ping Fan
>>> >
>>> > Collect unused object and release them at caller demand.
>>> >
>> Please explain the motivation for this patch
On 08/08/2012 12:05 PM, 陳韋任 (Wei-Ren Chen) wrote:
>> I propose we use gcc builtins. We get automatic architecture support,
>> and tuning for newer processors if the user so chooses.
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
>>
>> In May 2031 we can switch to C11 atom
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> The types of referred object by MemoryRegion are variable, ex,
> another mr, DeviceState, or other struct defined by drivers.
> So the refer/unrefer may be different by drivers.
>
> Using this ops, we can mange the backend obje
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Using refcnt for mr, so we can separate mr's life cycle management
> from refered object.
> When mr->ref 0->1, inc the refered object.
> When mr->ref 1->0, dec the refered object.
>
> The refered object can be DeviceStae, a
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> PhysMap contain the flatview and radix-tree view, they are snapshot
> of system topology and should be consistent. With PhysMap, we can
> swap the pointer when updating and achieve the atomic.
>
> Signed-off-by: Liu Ping Fan
>
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Flatview and radix view are all under the protection of pointer.
> And this make sure the change of them seem to be atomic!
>
> The mr accessed by radix-tree leaf or flatview will be reclaimed
> after the prev PhysMap not in us
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
Please explain the motivation. AFAICT, the big qemu lock is sufficient.
--
error compiling committee.c: too many arguments to function
On 08/08/2012 12:04 PM, Markus Armbruster wrote:
>>
>> Yes please, maybe with a notice to the user.
>
> Next problem: minimum RAM size.
>
> For instance, -M pc -m X, where X < 32KiB dies "qemu: fatal: Trying to
> execute code outside RAM or ROM at [...] Aborted (core dumped)" with
> TCG, and "KVM
On 08/08/2012 12:52 PM, Paolo Bonzini wrote:
> Il 08/08/2012 08:25, Liu Ping Fan ha scritto:
>> +void qdev_unplug_complete(DeviceState *dev, Error **errp)
>> +{
>> +/* isolate from mem view */
>> +qdev_unmap(dev);
>> +qemu_lock_devtree();
>> +/* isolate from device tree */
>> +q
On 08/08/2012 04:49 PM, Paolo Bonzini wrote:
> Il 08/08/2012 15:32, Peter Maydell ha scritto:
>>> > 1. GCC atomics look ugly, :) do not provide rmb/wmb, and in some
>>> > versions of GCC mb is known to be (wrongly) a no-op.
>>> >
>>> > 2. glib atomics do not provide mb/rmb/wmb either, and
>>> > g_a
On 08/09/2012 10:49 AM, Paolo Bonzini wrote:
> Il 09/08/2012 09:33, liu ping fan ha scritto:
>> Yes, it is to defer destructors.
>> See 0009-memory-prepare-flatview-and-radix-tree-for-rcu-style.patch
>> When MemoryRegion is _del_subregion from mem in updater, it may be
>> still in use by reader --
On 08/09/2012 10:28 AM, liu ping fan wrote:
>>
>> Seems to me that nothing in memory.c can susceptible to races. It must
>> already be called under the big qemu lock, and with the exception of
>> mutators (memory_region_set_*), changes aren't directly visible.
>>
> Yes, what I want to do is "prepa
On 08/09/2012 10:27 AM, liu ping fan wrote:
> On Wed, Aug 8, 2012 at 5:42 PM, Avi Kivity wrote:
>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>
>> Please explain the motivation. AFAICT, the big qemu lock is sufficient.
>&
On 08/09/2012 10:27 AM, liu ping fan wrote:
> On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity wrote:
>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> Using refcnt for mr, so we can separate mr's life cycle management
>>>
On 08/09/2012 12:55 PM, Amit Shah wrote:
> On (Thu) 09 Aug 2012 [18:24:58], Masami Hiramatsu wrote:
>> (2012/08/09 18:03), Amit Shah wrote:
>> > On (Tue) 24 Jul 2012 [11:37:18], Yoshihiro YUNOMAE wrote:
>> >> From: Masami Hiramatsu
>> >>
>> >> Add a failback memcpy path for unstealable pipe buffer
On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> Running under a kvm host does not necessarily imply the presence of
> a page mapped above the main memory with the virtio information;
> however, the code includes a hard coded access to that page.
>
> Instead, check for the presence of the page and e
On 08/07/2012 06:11 PM, Peter Maydell wrote:
> On 2 August 2012 10:14, Jan Kiszka wrote:
>> On 2012-07-26 16:35, Peter Maydell wrote:
>>> This patch series removes all uses of kvm_irqchip_in_kernel()
>>> from architecture-independent code, by creating a set of more
>>> specific functions instead t
On 08/10/2012 09:44 AM, liu ping fan wrote:
>>> In the previous discussion, you have suggest add dev->ref++ in
>>> core_region_add. But I think, if we can move it to higher layer --
>>> memory_region_{add,del}_subregion, so we can avoid to duplicate do
>>> this in other xx_region_add.
>>
>> Why wo
On 08/09/2012 09:06 PM, Bhushan Bharat-R65777 wrote:
> I have a fedora machine to which I do not have direct access (but I can
> reboot remotely, have a console). So far what I was trying direct booting VM
> using same initramfs and bzimage as of host,
>
> Alex, How I can create a ISO image wit
On 08/09/2012 07:33 PM, Peter Maydell wrote:
> Enable KVM on ARM hosts, now that all the necessary components
> for it exist.
>
> esac
> case "$target_arch2" in
> - i386|x86_64|ppcemb|ppc|ppc64|s390x)
> + arm|i386|x86_64|ppcemb|ppc|ppc64|s390x)
> # Make sure the target and host cpus are c
Please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
This is mostly Peter's kvm_irqchip_in_kernel() decoupling work.
Dunrong Huang (1):
kvm: Check if smp_cpus exceeds max cpus supported by kvm
Pet
On 08/13/2012 04:41 PM, Markus Armbruster wrote:
> Avi Kivity writes:
>
>> On 08/08/2012 12:04 PM, Markus Armbruster wrote:
>>>>
>>>> Yes please, maybe with a notice to the user.
>>>
>>> Next problem: minimum RAM size.
>>>
>>
On 08/13/2012 04:27 PM, Anthony Liguori wrote:
> Thanks for pushing this forward! Hopefully this will finally kill off
> qemu-kvm.git for good.
No, it won't. vfio requires a 3.6 kernel, which we cannot assume anyone
has. We'll need the original device assignment code side-by-side.
--
error c
On 08/13/2012 05:02 PM, Gleb Natapov wrote:
>> IMO we need to fix CMOS reporting.
>>
>> (technically we shouldn't touch CMOS NVRAM at all; seabios should
>> discover memory size via fwcfg and program it itself. But it's
>> pointless to change it now)
>>
> Chipset we emulate does not support all
On 08/14/2012 11:44 AM, Markus Armbruster wrote:
>
> Next error:
>
> $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor
> stdio -m 640k
> [...]
> Program received signal SIGSEGV, Segmentation fault.
> [...]
> (gdb) bt
> #0 0x003b0de884ac in __m
On 08/14/2012 11:30 AM, liu ping fan wrote:
> To make memoryRegion survive without the protection of qemu big lock,
> we need to pin its based Object.
> In current code, the type of mr->opaque are quite different. Lots of
> them are Object, but quite of them are not yet.
>
> The most challenge fo
On 08/14/2012 01:44 PM, Jan Kiszka wrote:
> On 2012-08-14 12:20, Avi Kivity wrote:
>> On 08/14/2012 11:44 AM, Markus Armbruster wrote:
>>>
>>> Next error:
>>>
>>> $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0
>>> -monito
On 08/14/2012 10:33 AM, Jan Kiszka wrote:
>
> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
> injection with feedback to allow lost-tick compensation) is the current
> standard that other archs should pick up.
KVM_IRQ_LINE_STATUS may not make sense on all architectures.
I don't
On 08/14/2012 02:58 PM, Markus Armbruster wrote:
> Partial pages make little sense and don't work. Ensure the RAM size
> is a multiple of any possible target's page size.
>
> index d01256a..b411d45 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2708,11 +2708,13 @@ int main(int argc, char **argv, char **e
On 08/14/2012 02:05 PM, Jan Kiszka wrote:
> On 2012-08-14 13:01, Avi Kivity wrote:
>> On 08/14/2012 10:33 AM, Jan Kiszka wrote:
>>>
>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
>>> injection with feedback to allow lost-tick compensati
On 08/14/2012 02:01 PM, Jan Kiszka wrote:
>>> We can also easily automatically disable it when there is insufficient
>>> (<1MB) memory. Will post a patch.
>>
>> Would be nicer if it auto-disables itself, but don't know if the option
>> ROM has access to the memory size.
>
> There is that global
On 08/14/2012 02:12 PM, Markus Armbruster wrote:
> Avi Kivity writes:
>
>> On 08/14/2012 11:44 AM, Markus Armbruster wrote:
> [...]
>>> And another one:
>>>
>>> $ qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor
>>> stdio -m
On 08/14/2012 04:25 PM, Jan Kiszka wrote:
> On 2012-08-14 15:16, Avi Kivity wrote:
>> On 08/14/2012 02:01 PM, Jan Kiszka wrote:
>>
>>>>> We can also easily automatically disable it when there is insufficient
>>>>> (<1MB) memory. Will post a pat
On 08/14/2012 08:27 AM, Alex Williamson wrote:
>> >
>> > Do we need this level of control? Open question I'm just wondering every
>> > time a new feature gets added together with --disable/--enable
>> > switches.
>>
>> I don't think so--it's easy enough for an administrator to disable vfio
>> for
On 08/13/2012 10:31 PM, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> On 2012-08-13 15:58, Avi Kivity wrote:
>>> On 08/13/2012 04:27 PM, Anthony Liguori wrote:
>>>
>>>> Thanks for pushing this forward! Hopefully this will finally kill off
>>
On 08/01/2012 08:18 AM, Alex Williamson wrote:
> This adds the core of the QEMU VFIO-based PCI device assignment driver.
> To make use of this driver, enable CONFIG_VFIO, CONFIG_VFIO_IOMMU_TYPE1,
> and CONFIG_VFIO_PCI in your host Linux kernel config. Load the vfio-pci
> module. To assign device
On 08/14/2012 08:23 PM, Alex Williamson wrote:
>
>> Unrelated nit: memcmp() doesn't return a boolean or a count, so
>> !memcmp() is really unintuitive, at least to me.
>
> I figure we're all pretty used to it growing up on !strcmp though.
I hate that one too.
>> > +
>> > +/* XXX This should mov
On 08/15/2012 02:44 PM, Michael Tokarev wrote:
> On 15.08.2012 13:31, Markus Armbruster wrote:
>> There are more, but let's start with these two.
>
> Yes, there are more of the same theme. In particular,
> why transparent huge pages support has never been
> applied? IIRC it went to nowhere after
On 08/15/2012 03:45 PM, Michael Tokarev wrote:
>
> But apparently, THP does not work still, even with 2Mb
> alignment: when running a guest, AnonHugePages in
> /proc/meminfo stays at 0 - either in kvm mode or in tcg
> mode. Any idea why? What else is needed for THP to work?
It does for me:
Ano
s version up a little from the RFC to make it a bit
> easier to review. Review comments from Blue Swirl and Avi are
> already incorporated, including Avi's requests to simplify both
> the PCI BAR mapping and unmapping paths.
Reviewed-by: Avi Kivity
--
error compiling committee.c: too many arguments to function
On 08/15/2012 05:22 PM, Michael Tokarev wrote:
>>
>> Please provide extra info, like the setting of
>> /sys/kernel/mm/transparent_hugepage/enabled.
>
> That was it - sort of. Default value here is enabled=madvise.
> When setting it to always the effect finally started appearing,
> so it is actu
On 08/16/2012 06:22 AM, liu ping fan wrote:
> On Tue, Aug 14, 2012 at 6:49 PM, Avi Kivity wrote:
>> On 08/14/2012 11:30 AM, liu ping fan wrote:
>>> To make memoryRegion survive without the protection of qemu big lock,
>>> we need to pin its based Object.
>>
On 08/16/2012 02:13 PM, Yin Olivia-R63875 wrote:
> Hi Avi & Ben,
>
> I've got feedback from qemu-ppc list and revised this patch according to
> Blue's comments.
> Could you please give any comments?
I don't really have any comments, those files are outside my area of
expertise. They look okay
On 08/16/2012 01:47 PM, Richard Davies wrote:
> Hi,
>
> We run a cloud hosting provider using qemu-kvm 1.1, and are keen to find a
> contractor to track down and fix problems we have with large memory Windows
> guests booting very slowly - they can take several hours.
>
> We previously reported t
On 08/17/2012 03:36 PM, Richard Davies wrote:
> Hi Avi,
>
> Thanks to you and several others for offering help. We will work with Avi at
> first, but are grateful for all the other offers of help. We have a number
> of other qemu-related projects which we'd be interested in getting done, and
> wil
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
>
>>> Can anyone imagine that such a barrier may actually be required? If it
>>> is currently possible that env->stop is evaluated before we called into
>>> sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
>>> signal without properly p
On 08/17/2012 01:55 PM, Jan Kiszka wrote:
> On 2012-07-10 12:41, Jan Kiszka wrote:
>> On 2012-07-02 11:07, Avi Kivity wrote:
>>> On 06/29/2012 07:37 PM, Jan Kiszka wrote:
>>>> Instead of flushing pending coalesced MMIO requests on every vmexit,
>>>> this
On 08/17/2012 05:52 AM, liu ping fan wrote:
>>
>> Why? Usually there's a 1:1 mapping between object and opaque. Can you
>> show cases where there isn't?
>>
> As mentioned ahead, setup_cmd646_bar(PCIIDEState *d, int bus_num),
> Object=@d, but opaque are
> d->cmd646_bar[bus_num], so that is 1:n map
On 08/17/2012 10:41 AM, liu ping fan wrote:
>> The same example, in setup_cmd646_bar(PCIIDEState *d, int bus_num), I
>> think we can not decide which is the type for @bar. If using
>> object_dynamic_cast(@bar, TYPE_OBJECT) to tell whether it is Object or
>> not, it will raise exception.
>>
> And
On 08/19/2012 02:23 PM, Peter Maydell wrote:
> On 19 August 2012 11:12, Avi Kivity wrote:
>> On 08/17/2012 10:41 AM, liu ping fan wrote:
>>> And something like omap_mpu_timer_init() in file hw/omap1.c , the
>>> opaque(omap_mpu_timer_s) is got from g_malloc0, which make
On 08/17/2012 03:36 PM, Richard Davies wrote:
> Hi Avi,
>
> Thanks to you and several others for offering help. We will work with Avi at
> first, but are grateful for all the other offers of help. We have a number
> of other qemu-related projects which we'd be interested in getting done, and
> wil
ipxe contains the following snippet:
/* Copy ROM to image source PMM block */
pushw %es
xorw%ax, %ax
movw%ax, %es
movl%esi, %edi
xorl%esi, %esi
movzbl romheader_size, %ecx
shll$9, %ecx
addr32 rep movsb
On 08/19/2012 06:34 PM, Michael Brown wrote:
> On Sunday 19 Aug 2012 16:07:05 Avi Kivity wrote:
>> Which is exactly what happens here. My understanding of big real mode is
>> that to achieve a segment limit != 0x, you must go into 32-bit
>> protected mode, load a segmen
On 08/19/2012 06:44 PM, Kevin O'Connor wrote:
> On Sun, Aug 19, 2012 at 06:07:05PM +0300, Avi Kivity wrote:
>> ipxe contains the following snippet:
>>
>> /* Copy ROM to image source PMM block */
>> pushw %es
>> xorw%ax, %ax
>>
On 08/21/2012 07:48 AM, liu ping fan wrote:
> On Sun, Aug 19, 2012 at 7:36 PM, Avi Kivity wrote:
>> On 08/19/2012 02:23 PM, Peter Maydell wrote:
>>> On 19 August 2012 11:12, Avi Kivity wrote:
>>>> On 08/17/2012 10:41 AM, liu ping fan wrote:
>>>>> And
On 08/20/2012 04:56 PM, Richard Davies wrote:
> We're running host kernel 3.5.1 and qemu-kvm 1.1.1.
>
> I hadn't though about it, but I agree this is related to cpu overcommit. The
> slow boots are intermittent (and infrequent) with cpu overcommit whereas I
> don't think it occurs without cpu ove
On 08/21/2012 12:03 PM, Christian Borntraeger wrote:
> On 10/08/12 15:11, Christian Borntraeger wrote:
>> valgrind with kvm produces a big amount of false positives regarding
>> "Conditional jump or move depends on uninitialised value(s)". This
>> happens because the guest memory is allocated with
On 08/21/2012 12:25 PM, liu ping fan wrote:
> On Tue, Aug 21, 2012 at 4:57 PM, Avi Kivity wrote:
>> On 08/21/2012 07:48 AM, liu ping fan wrote:
>>> On Sun, Aug 19, 2012 at 7:36 PM, Avi Kivity wrote:
>>>> On 08/19/2012 02:23 PM, Peter Maydell wrote:
>>>
On 08/20/2012 11:07 PM, Stefan Weil wrote:
> While I personally prefer (1) and used it for my first contributions,
> QEMU introduced qemu-common.h. I had the impression that from then on
> QEMU preferred strategy (2). Obviously not everybody shares that
> impression.
>
> Which strategy / rule do
On 08/21/2012 02:18 PM, liu ping fan wrote:
>>
>>> But as
>>> it will also take the code path which has object_ref(Object*), so it
>>> has to convert, otherwise the code will corrupt.
>>> That is what I want to express.
>>
>> Option 2, for example, had MemoryRegionOps::object(MemoryRegion *) which
On 08/21/2012 06:42 PM, Eduardo Habkost wrote:
> So, here's a third suggestion to the CPU/DeviceState problem. Basically I
> split
> the qdev code into a core (that can be easily compiled into *-user), and a
> part
> specific to qemu-system-*.
>
I'm barging in late here, so sorry if this has be
On 08/21/2012 06:21 PM, Richard Davies wrote:
> Avi Kivity wrote:
>> Richard Davies wrote:
>> > We're running host kernel 3.5.1 and qemu-kvm 1.1.1.
>> >
>> > I hadn't though about it, but I agree this is related to cpu overcommit.
>> > The
On 08/21/2012 12:28 PM, Tomas Racek wrote:
>
> http://fi.muni.cz/~xracek/debian2.img.bz2
>
> Other things are the same.
>
> The runtest.sh sets environment for xfstests and runs test 285 which I wrote
> and and which should test if FS sends discard requests only on free sectors:
> 285:
> 1. Cre
On 08/22/2012 12:54 PM, Avi Kivity wrote:
> On 08/21/2012 12:28 PM, Tomas Racek wrote:
>>
>> http://fi.muni.cz/~xracek/debian2.img.bz2
>>
>> Other things are the same.
>>
>> The runtest.sh sets environment for xfstests and runs test 285 which I wrote
&
On 08/22/2012 03:40 PM, Richard Davies wrote:
>
> I can trigger the slow boots without KSM and they have the same profile,
> with _raw_spin_lock_irqsave and isolate_freepages_block at the top.
>
> I reduced to 3x 20GB 8-core VMs on a 128GB host (rather than 3x 40GB 8-core
> VMs), and haven't mana
On 08/22/2012 02:47 PM, Alexander Graf wrote:
>>
>> Ok, so IIUC, that means we do need the cpu_physical_memory_write_rom()
>> version for load_image_targphys(), and so my original patch is
>> basically the right fix.
>
> Sure it is, I don't think anyone argued about that :). But it's duplicating
On 08/22/2012 05:41 PM, Richard Davies wrote:
> Avi Kivity wrote:
>> Richard Davies wrote:
>> > I can trigger the slow boots without KSM and they have the same profile,
>> > with _raw_spin_lock_irqsave and isolate_freepages_block at the top.
>> >
>> &g
On 08/27/2012 12:47 AM, Jan Kiszka wrote:
> On 2012-08-27 09:01, Paolo Bonzini wrote:
> > Il 25/08/2012 09:42, liu ping fan ha scritto:
>
> I don't see why MMIO dispatch should hold the IDEBus ref rather than the
> PCIIDEState.
>
> >> When transfer memory_region_init_io() 3rd p
On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> >
> > Deregistration is fine, the problem is destruction.
> >
>
> It isn't as you access memory region states that can change after
> deregistration. Devices can remove memory regions from the mapping,
> alter and then reinsert them. The last to steps m
On 08/27/2012 11:17 AM, Jan Kiszka wrote:
> On 2012-08-27 20:09, Avi Kivity wrote:
> > On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> >>>
> >>> Deregistration is fine, the problem is destruction.
> >>>
> >>
> >> It isn't as you a
On 08/27/2012 06:19 AM, Anthony Liguori wrote:
> Liu Ping Fan writes:
>
> > From: Liu Ping Fan
> >
> > Scene:
> > obja lies in objA, when objA's ref->0, it will be freed,
> > but at that time obja can still be in use.
> >
> > The real example is:
> > typedef struct PCIIDEState {
> > PCIDevi
On 08/27/2012 09:24 AM, Anthony Liguori wrote:
> >
> > I'm sure we should leave existing code alone wherever possible, focusing
> > on providing alternative versions for those paths that matter. Example:
> > Most timers are fine under BQL. But some sensitive devices (RTC or HPET
> > as clock source
On 08/27/2012 11:39 AM, Jan Kiszka wrote:
> On 2012-08-27 20:20, Avi Kivity wrote:
> > On 08/27/2012 11:17 AM, Jan Kiszka wrote:
> >> On 2012-08-27 20:09, Avi Kivity wrote:
> >>> On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> >>>>>
> >&
On 08/27/2012 12:38 PM, Jan Kiszka wrote:
> >> Even worse, apply
> >> restrictions on how the dispatched objects, the regions, have to be
> >> treated because of this.
> >
> > Please elaborate.
>
> The fact that you can't manipulate a memory region object arbitrarily
> after removing it from the m
On 08/27/2012 12:17 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
> > On 08/27/2012 09:24 AM, Anthony Liguori wrote:
> >> >
> >> > I'm sure we should leave existing code alone wherever possible, focusing
> >> > on providing alte
On 01/23/2012 07:18 PM, Anthony Liguori wrote:
> Generally speaking, RAM is an independent device in most useful cases.
Can you give examples? Do you mean a subdevice with composition, or a
really independent device?
> Onboard RAM is a very special case because it's extremely unusual.
What's
On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> >>>
> >>> But viewing RAM as just another device, having Xen only restore a
> >>> subset of
> >>> devices should be a reasonable thing to do moving forward.
>
> I don't think modeling device memory (i.e. vga vram) as something
> independent from the de
On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
> On 01/24/2012 12:10 PM, Avi Kivity wrote:
>>> But viewing RAM as just another device, having Xen only restore a
>>> subset of devices should be a reasonable thing to do moving forward.
>>> The main problem here I belie
On 01/22/2012 03:06 PM, Blue Swirl wrote:
> Let's compile Cirrus in hwlib.
>
> http://repo.or.cz/r/qemu/blueswirl.git
>
>
Patches look fine (after fixing #2). But please post patches using
git-send-email, otherwise they're unthreaded and lose their grouping as
soon as someone replies.
--
error
On 01/19/2012 08:54 PM, Jan Kiszka wrote:
> Nope, see kvm_irqchip_create, patch 13. You can also check by browsing
> the qtree (different device model names).
That was my biggest objection to the previous iterations. Later
versions changed to use an attribute (selecting the backend). What
happen
On 01/24/2012 04:10 PM, Jan Kiszka wrote:
> On 2012-01-24 15:05, Avi Kivity wrote:
> > On 01/19/2012 08:54 PM, Jan Kiszka wrote:
> >> Nope, see kvm_irqchip_create, patch 13. You can also check by browsing
> >> the qtree (different device model names).
> >
> &g
On 01/24/2012 02:00 PM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
> > On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > > >>>
> > > >>> But viewing RAM as just another device, having Xen only restore a
> > > >>>
On 01/24/2012 03:18 PM, Anthony Liguori wrote:
> On 01/24/2012 05:13 AM, Avi Kivity wrote:
>> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
>>>>>>
>>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>>> sub
On 01/24/2012 03:25 PM, Anthony Liguori wrote:
>
>>
To my understanding, QXL will break identically on Xen for the same
reason: the reset handler assumes it can deal with the VRAM as it
likes.
>>
>> Yes. Some data structures for host<-> guest communication are living
>> in device m
On 01/24/2012 01:44 PM, Paolo Bonzini wrote:
> On 01/24/2012 12:32 PM, Avi Kivity wrote:
>>> > Clearing the screen should only write to the RAM at 0xB8000 (and
>>> > perhaps 0xA since IIRC it's where text-mode fonts lie). The
>>> > option ROM
On 01/24/2012 03:14 PM, Anthony Liguori wrote:
> On 01/24/2012 05:10 AM, Avi Kivity wrote:
>> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>>> Generally speaking, RAM is an independent device in most useful cases.
>>
>> Can you give examples? Do you mean a su
On 01/19/2012 07:39 PM, Jan Kiszka wrote:
> On 2012-01-19 18:28, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2012 at 01:46:39PM +0100, Jan Kiszka wrote:
> >> Hi again,
> >>
> >> do we need some KVM knob comparable to qemu-kvm's -kvm-shadow-memory in
> >> upstream?
> >>
> >> If yes: The underlying IO
On 01/19/2012 04:16 PM, Stefano Stabellini wrote:
> >
> > If you are migrating to a newer qemu then the could in
> > principal change, I think.
>
> Not unless the implementation of qemu_ram_alloc_from_ptr or
> find_ram_offset change, but these are core qemu functions.
Both of these functions wil
On 01/25/2012 01:26 PM, Orit Wasserman wrote:
> Implement Unsigned Little Endian Base 128.
>
>
> +/* ULEB128 */
> +int uleb128_encode_small(uint8_t *out, uint32_t n);
> +int uleb128_decode_small(const uint8 *in, uint32_t *n);
> +
> #endif
> diff --git a/savevm.c b/savevm.c
> index 80be1ff..304db
1 - 100 of 4803 matches
Mail list logo
