** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1490611
Title:
Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to
the result
We have encountered the same problem.
We have a 1.4 GB size vmdk image and after converting it to vhdx, its size is
62GB. But qemu-img info show the size is 2.9 G.
===
$ qemu-img info dd_test.vmdk
image: dd_test.vmdk
file format: vmdk
virtual size: 250G (268435456000 bytes)
disk size: 1.4
qemu-img version is 1.5.3. I also use newer version to do the
conversion, it has the same result.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1399191
Title:
Large VHDX image size
Status in QEMU:
Sorry.
Please ignore above change. I just find that I change the status of this bug
https://bugs.launchpad.net/qemu/+bug/1490611
I really don't know I have privilege to modify that.
Sorry again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
For the status change, I am really sorry.
I think at that time, I just want to check the status/history of this bug, but
I maybe click certain button by mistake.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad
ciate your thoughts on this
Best regards
Jan Louw
CTO AITechGroup
South Africa
https://aitechgroup.co.za/
On 2012-08-13 10:35, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> This is required to get past the following assert with:
>
> commit 1523ed9e1d46b0b54540049d491475ccac7e6421
> Author: Jan Kiszka
> Date: Thu May 17 10:32:39 2012 -0300
>
> virtio
On 2012-08-12 11:24, Michael Tokarev wrote:
> On 12.08.2012 12:10, Gleb Natapov wrote:
> []
>> Any chance to bisect it?
>
> The bisecion leads to this commit:
>
> commit 17ee47418e65b1593defb30edbab33ccd47fc1f8
> Merge: 13b0496 5d17c0d
> Author: Jan Kiszka
>
On 2012-08-13 15:16, Michael Tokarev wrote:
> On 13.08.2012 17:07, Jan Kiszka wrote:
> []
>>> The bisecion leads to this commit:
>>>
>>> commit 17ee47418e65b1593defb30edbab33ccd47fc1f8
>>> Merge: 13b0496 5d17c0d
>>> Author: Jan Kiszka
>>&
anyone
> has. We'll need the original device assignment code side-by-side.
...which is on my to-do list for 1.3.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
On 2012-08-13 20:03, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 02:06:10PM +0200, Jan Kiszka wrote:
>> On 2012-08-13 10:35, Nicholas A. Bellinger wrote:
>>> From: Nicholas Bellinger
>>>
>>> This is required to get past the f
offset also on kvm_pit_put. For this purpose,
we cache the clock offset in KVMPITState, only updating it on VM state
changes or when we write the state while the VM is stopped.
Signed-off-by: Jan Kiszka
---
hw/kvm/i8254.c | 52 ++--
1 files changed
On 2012-08-13 21:31, 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
>>>&
s->irqchip_inject_ioctl = KVM_IRQ_LINE_STATUS;
> }
Either you move both or none.
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.
Jan
signature.asc
Description: OpenPGP digital signature
RQ_LINE_STATUS seems to be undocumented,
> incidentally. I am going to assume it's another x86ism until somebody
> does document it :-))
Oh, and when implementing KVM_IRQ_LINE_STATUS for ARM, please also feel
free to document it in a way that it applies both to its x86 history and
new architectures.
Jan
signature.asc
Description: OpenPGP digital signature
On 2012-08-13 20:40, Michael Tokarev wrote:
> On 13.08.2012 22:18, Jan Kiszka wrote:
>> 0cdd3d1444 fixed reading back the counter load time from the kernel
>> while assuming the kernel would always update its load time on writing
>> the state. That is only true
On 2012-08-14 09:40, Peter Maydell wrote:
> On 14 August 2012 08:33, Jan Kiszka wrote:
>> Either you move both or none.
>
> OK.
>
>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
>> injection with feedback to allow lost-tick compensation) is the
On 2012-08-14 09:52, Peter Maydell wrote:
> On 14 August 2012 08:42, Jan Kiszka wrote:
>> On 2012-08-14 09:40, Peter Maydell wrote:
>>> On 14 August 2012 08:33, Jan Kiszka wrote:
>>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
>>>>
while the VM is running.
Signed-off-by: Jan Kiszka
---
hw/kvm/i8254.c | 38 --
1 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/hw/kvm/i8254.c b/hw/kvm/i8254.c
index c5d3711..c235d80 100644
--- a/hw/kvm/i8254.c
+++ b/hw/kvm/i8254.c
@@ -35,7
offset also on kvm_pit_put. Now we also need to
update the offset when we write the state while the VM is stopped as it
keeps on changing in that state.
Signed-off-by: Jan Kiszka
---
hw/kvm/i8254.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/kvm/i8254.c
Say libvirtd could take an action upon
>> that?
>
> No, this is not satisfactory. It depends on the guest OS being
> configured to use the serial port for console output which we
> cannot mandate, since it may well be required for other purposes.
Well, we have more than a single serial port, even when leaving
virtio-serial aside...
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
he ROM. We could fix up
> kvmvapic to allocate a 4k region and insert it as an overlay, but it's
> sufficient IMO to require sub-1M users to disable it. It won't be of
> any use to the anyway as Windows XP requires more than 1MB.
We can also easily automatically disable it when there is insufficient
(<1MB) memory. Will post a patch.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
On 2012-08-14 12:51, Avi Kivity wrote:
> 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
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 compensation) is the current
>> standard that other archs should pick u
We need at least 1M of RAM to map the option ROM. Otherwise, we will
corrupt host memory or even crash.
Reported-by: Markus Armbruster
Signed-off-by: Jan Kiszka
---
hw/apic_common.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/apic_common.c b/hw/apic_common.c
On 2012-07-20 09:17, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Since we moved pcspk into hwlib, CONFIG_PCSPK is no longer defined per
> target. Therefore, statically built soundhw array in arch_init.c stopped
> including this card.
>
> Work around this by re-adding
We need at least 1M of RAM to map the option ROM. Otherwise, we will
corrupt host memory or even crash:
$ qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -m 640k
Segmentation fault (core dumped)
Reported-and-tested-by: Markus Armbruster
Signed-off-by: Jan Kiszka
---
hw
On 2012-08-14 15:10, Peter Maydell wrote:
> On 14 August 2012 09:09, Jan Kiszka wrote:
>> On 2012-08-14 09:52, Peter Maydell wrote:
>>> Well, you appear to know what this variant ioctl does and why it's
>>> better than KVM_IRQ_LINE, whereas I don't. I
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 patch.
>>>
>>> Would be nicer if it auto-disabl
On 2012-08-14 15:14, Avi Kivity wrote:
> 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
>&
On 2012-08-14 16:55, Yan Vugenfirer wrote:
>
> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>
>> On 2012-08-14 10:56, Daniel P. Berrange wrote:
>>> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>>>> On Wed, Aug 08, 2012 at 10:43:01AM +08
On 2012-08-14 16:53, Cole Robinson wrote:
> On 08/13/2012 03: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
nit= vfio_pci_dev_class_init,
> +};
> +
> +static void register_vfio_pci_dev_type(void)
> +{
> +type_register_static(&vfio_pci_dev_info);
> +}
> +
> +type_init(register_vfio_pci_dev_type)
> diff --git a/hw/vfio_pci.h b/hw/vfio_pci.h
> new file mode 100644
> index 000..0a71bce
> --- /dev/null
> +++ b/hw/vfio_pci.h
> @@ -0,0 +1,101 @@
> +#ifndef HW_VFIO_PCI_H
> +#define HW_VFIO_PCI_H
> +
> +#include "qemu-common.h"
> +#include "qemu-queue.h"
> +#include "pci.h"
> +#include "event_notifier.h"
> +
> +typedef struct VFIOBAR {
> +off_t fd_offset; /* offset of BAR within device fd */
> +int fd; /* device fd, allows us to pass VFIOBAR as opaque data */
> +MemoryRegion mem; /* slow, read/write access */
> +MemoryRegion mmap_mem; /* direct mapped access */
> +void *mmap;
> +size_t size;
> +uint32_t flags; /* VFIO region flags (rd/wr/mmap) */
> +uint8_t nr; /* cache the BAR number for debug */
> +} VFIOBAR;
> +
> +typedef struct INTx {
> +bool pending; /* interrupt pending */
> +bool kvm_accel; /* set when QEMU bypass through KVM enabled */
> +uint8_t pin; /* which pin to pull for qemu_set_irq */
> +EventNotifier interrupt; /* eventfd triggered on interrupt */
> +EventNotifier unmask; /* eventfd for unmask on QEMU bypass */
> +PCIINTxRoute route; /* routing info for QEMU bypass */
> +} INTx;
Please add a VFIO prefix.
> +
> +struct VFIODevice;
> +
> +typedef struct MSIVector {
> +EventNotifier interrupt; /* eventfd triggered on interrupt */
> +struct VFIODevice *vdev; /* back pointer to device */
> +int vector; /* the vector number for this element */
Could also be calculated via vector - vector->vdev->msi_vectors. But I
don't mind.
> +int virq; /* KVM irqchip route for QEMU bypass */
> +bool use;
> +} MSIVector;
Also here. Just in case we ever decide to introduce a generic structure
with this name.
> +
> +enum {
> +INT_NONE = 0,
> +INT_INTx = 1,
> +INT_MSI = 2,
> +INT_MSIX = 3,
> +};
> +
> +struct VFIOGroup;
> +
> +typedef struct VFIOContainer {
> +int fd; /* /dev/vfio/vfio, empowered by the attached groups */
> +struct {
> +/* enable abstraction to support various iommu backends */
> +union {
> +MemoryListener listener; /* Used by type1 iommu */
> +};
> +void (*release)(struct VFIOContainer *);
> +} iommu_data;
> +QLIST_HEAD(, VFIOGroup) group_list;
> +QLIST_ENTRY(VFIOContainer) next;
> +} VFIOContainer;
> +
> +/* Cache of MSI-X setup plus extra mmap and memory region for split BAR map
> */
> +typedef struct MSIXInfo {
> +uint8_t table_bar;
> +uint8_t pba_bar;
> +uint16_t entries;
> +uint32_t table_offset;
> +uint32_t pba_offset;
> +MemoryRegion mmap_mem;
> +void *mmap;
> +} MSIXInfo;
Also a pretty generic name.
> +
> +typedef struct VFIODevice {
> +PCIDevice pdev;
> +int fd;
> +INTx intx;
> +unsigned int config_size;
> +off_t config_offset; /* Offset of config space region within device fd */
> +unsigned int rom_size;
> +off_t rom_offset; /* Offset of ROM region within device fd */
> +int msi_cap_size;
> +MSIVector *msi_vectors;
> +MSIXInfo *msix;
> +int nr_vectors; /* Number of MSI/MSIX vectors currently in use */
> +int interrupt; /* Current interrupt type */
> +VFIOBAR bars[PCI_NUM_REGIONS - 1]; /* No ROM */
> +PCIHostDeviceAddress host;
> +QLIST_ENTRY(VFIODevice) next;
> +struct VFIOGroup *group;
> +bool reset_works;
> +} VFIODevice;
> +
> +typedef struct VFIOGroup {
> +int fd;
> +int groupid;
> +VFIOContainer *container;
> +QLIST_HEAD(, VFIODevice) device_list;
> +QLIST_ENTRY(VFIOGroup) next;
> +QLIST_ENTRY(VFIOGroup) container_next;
> +} VFIOGroup;
> +
> +#endif /* HW_VFIO_PCI_H */
>
Why do all theses structs have to go into a header file? Will there be
more users than vfio_pci.c?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
/*
>>> + * We can't mmap areas overlapping the MSIX vector table, so we
>>> + * potentially insert a direct-mapped subregion before and after it.
>>> + */
>>> +if (vdev->msix && vdev->msix->table_bar == nr) {
>>> +
.
Signed-off-by: Jan Kiszka
---
configure |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index be292fe..672da59 100755
--- a/configure
+++ b/configure
@@ -3902,6 +3902,11 @@ if test "$target_bsd_user" = "yes" ; then
ech
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 provides a mechanism to selectively flush when memory regions
&
Signed-off-by: Jan Kiszka
---
hw/i82378.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/i82378.c b/hw/i82378.c
index 9b11d90..2123c14 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -225,7 +225,6 @@ static int pci_i82378_init(PCIDevice *dev)
pci_register_bar(dev
On 2012-08-17 13:13, Michael Tokarev wrote:
> On 17.08.2012 14:56, Jan Kiszka wrote:
>> This MMIO area is an entry gate to legacy PC ISA devices, addressed via
>> PIO over there. Quite a few of the PIO ports have side effects on access
>> like starting/stopping timers
first_cpu->stopped
> $10 = 0
> (gdb) p first_cpu->exit_request
> $11 = 0
CPUState::exit_request is only set on specific synchronous events, see
target-i386/kvm.c.
More interesting is CPUState::thread_kicked. If it's set, qemu_cpu_kick
will skip the kicking via a signal. Maybe there is some race. Let me
think about such possibilities again...
Jan
>
> :(
>
> This isn't easy to reproduce. I tried entering the GRUB boot menu
> again and there was no deadlock.
>
> Stefan
>
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
if (active_console->cursor_timer) {
> +if (active_console && active_console->cursor_timer) {
> qemu_del_timer(active_console->cursor_timer);
> }
> active_console = s;
>
The only path that could trigger this is console_select() in
On 2012-08-17 15:11, Jan Kiszka wrote:
> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>>> i debugged my initial problem further and found out that the problem happens
>>> to be that
>>> the main thread is
On 2012-08-17 16:36, Jan Kiszka wrote:
> On 2012-08-17 15:11, Jan Kiszka wrote:
>> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>>>> i debugged my initial problem further and found out that the problem
>>
On 2012-08-17 16:41, Jan Kiszka wrote:
> On 2012-08-17 16:36, Jan Kiszka wrote:
>> On 2012-08-17 15:11, Jan Kiszka wrote:
>>> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>>>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>>>>> i debugged my i
No need to expose the fd-based interface, everyone will already be fine
with the more handy EventNotifier variant. Rename the latter to clarify
that we are still talking about irqfds here.
Signed-off-by: Jan Kiszka
---
Alex, please update your vfio patch accordingly.
hw/virtio-pci.c |4
VCPUs are either resumed directly via vm_start, after the incoming
migration is done, or when a continue command is issued. We don't need
the explicit resume before entering main_loop.
Signed-off-by: Jan Kiszka
---
I was adding nesting support to pause/resume_all_vcpus, and that
stumbled
On 2012-08-19 11:42, Avi Kivity wrote:
> 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
>>>> sig
On 2012-08-21 09:01, Paolo Bonzini wrote:
> Il 20/08/2012 20:11, Jan Kiszka ha scritto:
>> VCPUs are either resumed directly via vm_start, after the incoming
>> migration is done, or when a continue command is issued. We don't need
>> the explicit resume before entering m
US)) {
> +s->irqchip_inject_ioctl = KVM_IRQ_LINE_STATUS;
> +}
> +
> ret = kvm_arch_init(s);
> if (ret < 0) {
> goto err;
>
As it's not yet merged, some late comment: irqchip_inject_ioctl should
be renamed as well. irq_inject_ioctl?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
On 2012-08-21 10:25, Peter Maydell wrote:
> On 21 August 2012 09:19, Jan Kiszka wrote:
>> On 2012-08-15 13:08, Peter Maydell wrote:
>>> Move the init of the irqchip_inject_ioctl field of KVMState out of
>>> kvm_irqchip_create() and into kvm_init(), so that kvm_set_irq(
t;> +addr1, (0xff & ~CODE_DIRTY_FLAG));
>>> +}
>>
>> Can't we just call cpu_physical_memory_rw in the RAM case? The
>> function only tries to not do MMIO accesses on ROM pages, right?
>
> Maybe. It's not clear at all to me what cases
> cpu_physical_memory_write_rom() is supposed to be for, as opposed to
> just using cpu_physical_memory_rw().
write_rom ignores write protection - that you usually find on ROMs. That
makes no difference under KVM so far as there we lack read-only
sections. But that will be fixed soon, patches are on the list.
Jan
signature.asc
Description: OpenPGP digital signature
On 2012-08-22 08:47, Jan Kiszka wrote:
> On 2012-08-22 07:57, David Gibson wrote:
>> On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
>>>
>>> On 22.08.2012, at 06:59, David Gibson wrote:
>>>
>>>> cpu_physical_memory_write_rom(),
{
> @@ -1661,7 +1661,7 @@ PixelFormat qemu_default_pixelformat(int bpp)
> memset(&pf, 0x00, sizeof(PixelFormat));
>
> pf.bits_per_pixel = bpp;
> -pf.bytes_per_pixel = bpp / 8;
> +pf.bytes_per_pixel = (bpp + 7) >> 3;
> pf.depth = bpp == 32 ? 24 : bpp;
>
> switch (bpp) {
Jan
signature.asc
Description: OpenPGP digital signature
support this case was removed a year ago.)
This is a rather big patch. I strongly suspect you can break it up into
smaller pieces that address separate aspects one-by-one. Also, it is
definitely to heavy for "qemu-trivial".
Jan
>
> Signed-off-by: BALATON Zoltan
> ---
>
ered.
>
> I'll continue to dig around, but can you explain what this assertion
> is catching. Is there an initialization that might be missing?
Possibly a double-release of the eventfd. The assertion checks if the
parameters provided on del_eventfd match an existing one. Or that
matching is broken.
Jan
signature.asc
Description: OpenPGP digital signature
oaded. The reason is that it injects a trap instruction in the guest
code, and that instruction will be overwritten during boot.
Use a hardware breakpoint instead, or interrupt the guest before the
interesting code is executed but after the kernel is loaded.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
t like -machine, i.e. with more than a machine
name, that would be a libvirt bug (but that would have been noticed much
earlier - did you patch something?). QEMU only keeps -M
around to please existing users that didn't switch yet. It is NOT an
alias for -machine.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
On 2012-08-22 12:19, BALATON Zoltan wrote:
> On Wed, 22 Aug 2012, Jan Kiszka wrote:
>> This is a rather big patch. I strongly suspect you can break it up into
>> smaller pieces that address separate aspects one-by-one. Also, it is
>> definitely to heavy for "qemu-trivi
, 0x00, sizeof(PixelFormat));
>
> pf.bits_per_pixel = bpp;
> -pf.bytes_per_pixel = bpp / 8;
> +pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
> pf.depth = bpp == 32 ? 24 : bpp;
>
> switch (bpp) {
> case 15:
> pf.bits_per_pixel = 16;
> -
On 2012-08-22 17:58, Martin Kletzander wrote:
> On 08/22/2012 05:15 PM, Jan Kiszka wrote:
>> On 2012-08-22 17:05, Martin Kletzander wrote:
>>> Hi everybody,
>>>
>>> while coding the support for Jason's dump-guest-core option I realized
>>> ther
On 2012-08-22 18:29, Stefan Weil wrote:
> Am 22.08.2012 17:32, schrieb Jan Kiszka:
>> On 2012-08-22 17:19, BALATON Zoltan wrote:
>>> Division with round up is the correct way to compute this even if the
>>> only case where division with round down gives incorrect re
On 2012-08-22 18:44, Jan Kiszka wrote:
> On 2012-08-22 18:29, Stefan Weil wrote:
>> Am 22.08.2012 17:32, schrieb Jan Kiszka:
>>> On 2012-08-22 17:19, BALATON Zoltan wrote:
>>>> Division with round up is the correct way to compute this even if the
>>>> only
;.
Also, just to double check: we don't currently expose the option of MMCONFIG
to the guest (as otherwise the change would be incomplete)?
Jan
and
another one below appears to be the case) is not allowed.
>+case HVM_PARAM_IO_PFN_FIRST:
I don't see where in this patch this and the other new sub-op constants
get defined.
Jan
; @@ -46,6 +46,9 @@
> #ifdef CONFIG_XEN
> # include
> #endif
> +#ifdef CONFIG_KVM
> +# include
> +#endif
>
> #define MAX_IDE_BUS 2
>
> @@ -285,6 +288,12 @@ static void pc_init1(MemoryRegion *system_memory,
> if (pci_enabled) {
> pc_pci_device_init(pci_bus);
> }
> +
> +#ifdef KVM_PV_EVENT_PORT
This file is x86-only, and there we have KVM_PV_EVENT_PORT
unconditionally. So drop the #ifdef.
> +if (kvm_enabled()) {
> +kvm_pv_event_init(isa_bus);
But you are missing a kvm-stub entry for kvm_pv_event_init. A
--disable-kvm build should be broken for that reason.
> +}
> +#endif
> }
>
> static void pc_init_pci(ram_addr_t ram_size,
> diff --git a/kvm.h b/kvm.h
> index 5b8f588..41ce1b2 100644
> --- a/kvm.h
> +++ b/kvm.h
> @@ -276,4 +276,6 @@ int kvm_irqchip_add_irqfd(KVMState *s, int fd, int virq);
> int kvm_irqchip_remove_irqfd(KVMState *s, int fd, int virq);
> int kvm_irqchip_add_irq_notifier(KVMState *s, EventNotifier *n, int virq);
> int kvm_irqchip_remove_irq_notifier(KVMState *s, EventNotifier *n, int virq);
> +
> +void kvm_pv_event_init(void *opaque);
> #endif
>
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
Flush pending coalesced MMIO before performing mapping or state changes
that could affect the event orderings or route the buffered requests to
a wrong region.
Signed-off-by: Jan Kiszka
---
memory.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
r relevant region state
changes.
Jan Kiszka (6):
memory: Flush coalesced MMIO on selected region access
memory: Use transaction_begin/commit also for single-step operations
memory: Fold memory_region_update_topology into
memory_region_transaction_commit
memory: Flush coalesced MMIO on m
No need for this indirection via qemu_notify_event. On Unix, we already
catch SIGALRM via signalfd (or its emulation) and run the handler
synchronously. Under Win32, handlers run in separate threads. So we just
need to grab the global lock around the handler execution.
Signed-off-by: Jan Kiszka
disabled or unregistered regions.
Signed-off-by: Jan Kiszka
---
memory.c | 40 +---
1 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/memory.c b/memory.c
index 835eb86..58583cf 100644
--- a/memory.c
+++ b/memory.c
@@ -1076,8 +1076,9 @@ void
The memory subsystem will now take care of flushing whenever affected
regions are accessed or the memory mapping changes.
Signed-off-by: Jan Kiszka
---
kvm-all.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index e0244b6..432b84f 100644
--- a
, by calling memory_region_set_flush_coalesced.
Signed-off-by: Jan Kiszka
---
memory.c | 24
memory.h | 26 ++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index 643871b..835eb86 100644
--- a/memory.c
+++ b
In preparation of stopping to flush coalesced MMIO unconditionally on
vmexits, mark VGA MMIO and PIO regions as synchronous /wrt coalesced
MMIO and flush the buffer explicitly on PIO accesses that do not use
generic memory regions yet.
Signed-off-by: Jan Kiszka
---
hw/cirrus_vga.c |7
Simplify the code as we are using now only a subset of the original
features of memory_region_update_topology.
Signed-off-by: Jan Kiszka
---
memory.c | 39 +++
1 files changed, 11 insertions(+), 28 deletions(-)
diff --git a/memory.c b/memory.c
index
On 2012-08-23 13:39, Paolo Bonzini wrote:
> Il 23/08/2012 13:23, Jan Kiszka ha scritto:
>> No need for this indirection via qemu_notify_event. On Unix, we already
>> catch SIGALRM via signalfd (or its emulation) and run the handler
>> synchronously. Under Win32, handlers ru
On 2012-08-23 14:24, Paolo Bonzini wrote:
> Il 23/08/2012 14:10, Jan Kiszka ha scritto:
>>> Can you expand on this?
>>
>> Well, this patch removes an indirection from timer event deliveries. So
>> it reduces overhead, though only noticeable if you have high-rate time
[likely not kvm related, CC'ing the appropriate community]
On 2012-08-23 18:16, Mike Gerber wrote:
> Hi,
>
> I'm using a KVM guest to stream audio using darkice to an icecast2 server on
> the
> same guest. The guest uses an emulated ES1370 sound card to capture the host's
> audio input (ASUS Xon
ve a registered region before registering a new one
Didn't look at the spec, but I bet that (config[0x80] & 1) == 0 means
disable this mapping. Should be fixed as well if that is true.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
_mipssim.c |3 +-
> hw/pc.c | 58 ++-
> hw/pc.h |2 +-
> hw/pm_smbus.c |7 +-
> hw/pm_smbus.h |6 +-
> hw/serial.c |8 ++-
> hw/vt82c686.c | 20 ++-
> 14 files changed, 325 insertions(+), 124 de
e above Windows but not much)?
Well, at least we should not regress.
For Windows I just found out that we support millisecond resolution in
os_host_main_loop_wait at best due to g_poll. That would be fine, but
what is g_poll really using? Likely not mm-timers...
Jan
--
Siemens AG, Corporate Techno
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 03e13ec..57bb0b4 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1188,6 +1188,18 @@ Windows 2000 is installed, you no longer need this
> option (this option
> slows down the IDE transfers).
> ETEXI
>
> +DEF("no-spurious-interrupt-hack", 0, QEMU_OPTION_no_spurious_interrupt_hack,
> +"-no-spurious-interrupt-hack disable delivery of spurious
> interrupts\n",
> +QEMU_ARCH_I386)
> +STEXI
> +@item -no-spurious-interrupt-hack
> +@findex -no-spurious-interrupt-hack
> +Use it as a workaround for operating systems that drive PICs in a way that
> +can generate spurious interrupts, but the OS doesn't handle spurious
> +interrupts gracefully. (e.g. late 80s/early 90s versions of ATT UNIX
> +and derivatives)
Has to mention or even actively warn that it doesn't work with KVM and
its in-kernel irqchip (as that PIC model lacks your hack).
However, I strongly suspect you are nastily papering over an issue in
some device model. So I would prefer to dig deeper before installing
this in upstream (also due to its dependency on the userspace PIC model).
Jan
signature.asc
Description: OpenPGP digital signature
ges.
>
> [..snip..]
>
> Applied, thanks.
Err, does this comply with the -rcX process? Patch 6 alone has been on
the list for less than a day. Only now I was able to comment on it, and
I would prefer to not have it merged that easily.
Jan
signature.asc
Description: OpenPGP digital signature
On 2012-08-24 01:13, Cam Macdonell wrote:
> Hi Jan,
>
> I've bisected a bug in which MSI interrupts are not being delivered to
> the following patch, where msix_reset was moved in tot he PCI core.
>
> commit cbd2d4342b3d42ab33baa99f5b7a23491b5692f2
> Author: Jan Kiszk
From: Jan Kiszka
This optimization was once used in qemu-kvm to keep KVM route usage low.
But now we solved that problem via lazy updates. It also tried to handle
the case of vectors shared between different sources of the same device.
However, this never really worked and will have to be
On 2012-08-24 08:05, Wen Congyang wrote:
> At 08/23/2012 06:51 PM, Jan Kiszka Wrote:
>> On 2012-08-23 04:32, Wen Congyang wrote:
>>> If the target is x86/x86_64, the guest's kernel will write 0x01 to the
>>> port KVM_PV_EVENT_PORT when it is panciked. This patch
On 2012-08-24 08:33, Wen Congyang wrote:
> At 08/24/2012 02:21 PM, Jan Kiszka Wrote:
>> On 2012-08-24 08:05, Wen Congyang wrote:
>>> At 08/23/2012 06:51 PM, Jan Kiszka Wrote:
>>>> On 2012-08-23 04:32, Wen Congyang wrote:
>>>>> If the target is x86/x86_
On 2012-08-24 10:11, Michael S. Tsirkin wrote:
> On Fri, Aug 24, 2012 at 07:59:06AM +0200, Jan Kiszka wrote:
>> On 2012-08-24 01:13, Cam Macdonell wrote:
>>> Hi Jan,
>>>
>>> I've bisected a bug in which MSI interrupts are not being delivered to
>>&g
On 2012-08-24 10:05, Matthew Ogilvie wrote:
> On Fri, Aug 24, 2012 at 07:40:36AM +0200, Jan Kiszka wrote:
>> On 2012-08-23 08:24, Matthew Ogilvie wrote:
>>> This patch provides a way to optionally suppress spurious interrupts,
>
> [snip]
>
>>> I'm no
On 2012-08-24 10:20, Michael S. Tsirkin wrote:
> On Fri, Aug 24, 2012 at 08:19:50AM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> This optimization was once used in qemu-kvm to keep KVM route usage low.
>> But now we solved that problem via lazy updates. It also
On 2012-08-24 10:21, Jan Kiszka wrote:
> On 2012-08-24 10:20, Michael S. Tsirkin wrote:
>> On Fri, Aug 24, 2012 at 08:19:50AM +0200, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> This optimization was once used in qemu-kvm to keep KVM route usage low.
>>
On 2012-08-24 10:36, Michael S. Tsirkin wrote:
> On Fri, Aug 24, 2012 at 10:15:33AM +0200, Jan Kiszka wrote:
>> On 2012-08-24 10:11, Michael S. Tsirkin wrote:
>>> On Fri, Aug 24, 2012 at 07:59:06AM +0200, Jan Kiszka wrote:
>>>> On 2012-08-24 01:13, Cam
On 2012-08-24 13:20, Stefan Hajnoczi wrote:
> On Wed, Aug 22, 2012 at 06:44:08PM +0200, Jan Kiszka wrote:
>> On 2012-08-22 18:29, Stefan Weil wrote:
>>> Am 22.08.2012 17:32, schrieb Jan Kiszka:
>>>> On 2012-08-22 17:19, BALATON Zoltan wrote:
>>>>>
This variable is no longer bound to irqchip, and the IOCTL sets the IRQ
level, does not directly inject it. No functional changes.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index d1924db
On 2012-08-24 14:02, malc wrote:
> On Fri, 24 Aug 2012, Jan Kiszka wrote:
>
>> On 2012-08-24 05:58, malc wrote:
>>> On Thu, 23 Aug 2012, Matthew Ogilvie wrote:
>>>
>>>> After applying this version 2 of this patch series, I can
>>>> success
er_ioport_read(0x3d4, 2, 1, cirrus_vga_ioport_read, s);
> -register_ioport_read(0x3ba, 1, 1, cirrus_vga_ioport_read, s);
> -register_ioport_read(0x3da, 1, 1, cirrus_vga_ioport_read, s);
> +/* Register ioport 0x3b0 - 0x3df */
> +memory_region_init_io(&s->cirrus_vg
On 2012-08-24 16:49, Julien Grall wrote:
> On 08/24/2012 02:44 PM, Jan Kiszka wrote:
>> On 2012-08-22 14:27, Julien Grall wrote:
>>
>>> This patch replaces all register_ioport* with portio_*. It permits to
>>> use the new Memory stuff like listener.
&g
f, 1, smb_ioport_writeb,
> &s->smb);
> -register_ioport_read(s->smb_io_base, 0xf, 1, smb_ioport_readb, &s->smb);
> +
> +memory_region_init_io(&s->smb_io, &smb_io_ops, &s->smb, "vt82c686b-smb",
> + 0xf);
> +memory_region_add_subregion(pci_address_space_io(dev), s->smb_io_base,
> +&s->smb_io);
>
> apm_init(dev, &s->apm, NULL, s);
>
>
This file is only half-converted. Working on the other bits...
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
From: Jan Kiszka
The last argument of find_portio is "write", so this must be true here.
Signed-off-by: Jan Kiszka
---
We were likely lucky so far and didn't hit this - it would have caused
an assertion. However, there are also rarely used devices...
memory.c |2 +-
1 f
t; +static void piix4_acpi_system_hot_add_init(PCIBus *bus, PIIX4PMState *s)
> +{
>
> -register_ioport_read(PCI_RMV_BASE, 4, 4, pcirmv_read, s);
> +memory_region_init_io(&s->acpi_hot_io, &acpi_hot_io_ops, s,
> + "piix4-acpi-hot", GPE_LEN);
> +memory_region_add_subregion(pci_address_space_io(&s->dev), GPE_BASE,
> +&s->acpi_hot_io);
> +acpi_gpe_blk(&s->ar, 0);
> +
> +portio_list_init(&s->pci_hot_port_list, pci_hot_portio_list, s,
> + "piix4-pci-hot");
> +portio_list_add(&s->pci_hot_port_list, pci_address_space_io(&s->dev),
> +PCI_BASE);
> +
> +memory_region_init_io(&s->pciej_hot_io, &pciej_hot_io_ops, s,
> + "piix4-pciej-hot", 4);
> +memory_region_add_subregion(pci_address_space_io(&s->dev), PCI_EJ_BASE,
> +&s->pciej_hot_io);
> +
> +memory_region_init_io(&s->pcirmv_hot_io, &pcirmv_hot_io_ops, s,
> + "piix4-pcirmv-hot", 4);
> +memory_region_add_subregion(pci_address_space_io(&s->dev), PCI_RMV_BASE,
> +&s->pcirmv_hot_io);
>
> pci_bus_hotplug(bus, piix4_device_hotplug, &s->dev.qdev);
> }
>
This patch doesn't build without patch 8 and then still generates warnings.
Jan
signature.asc
Description: OpenPGP digital signature
r + 0x10, val, size);
> }
> }
>
> @@ -2783,8 +2787,18 @@ static const MemoryRegionOps cirrus_linear_io_ops = {
> },
> };
>
> +static const MemoryRegionOps cirrus_vga_io_ops = {
> +.write = cirrus_vga_ioport_write,
Missing .read. Crashes immediately when you test it.
Jan
signature.asc
Description: OpenPGP digital signature
On 2012-08-26 11:10, Jan Kiszka wrote:
> On 2012-08-22 14:27, Julien Grall wrote:
>> This patch replaces all register_ioport* with the new memory API. It permits
>> to use the new Memory stuff like listener.
>>
>> Signed-off-by: Julien Grall
>&g
to me, see patch 1 for the clean procedure.
Jan
signature.asc
Description: OpenPGP digital signature
1 - 100 of 6074 matches
Mail list logo
