Public bug reported:
This bug has been tested with the latest development tree
(19b599f7664b2ebfd0f405fb79c14dd241557452).
I am using qemu-system-i386 with the gdbserver stub. I set a watchpoint
on some address. When the watchpoint is hit, it will be reported by gdb,
but it might happen that eip
On Fri, Sep 14, 2018 at 01:26:57PM -0500, Brijesh Singh wrote:
> The vtd_generate_msi_message() in intel-iommu is used to construct a MSI
> Message from IRQ. A similar function will be needed when we add interrupt
> remapping support in amd-iommu. Moving the function in common file to
> avoid the
On Fri, Sep 14, 2018 at 01:26:56PM -0500, Brijesh Singh wrote:
> Interrupt remapping needs kernel-irqchip={off|split} on both Intel and AMD
> platforms. Move the check in common place.
>
> Signed-off-by: Brijesh Singh
> Reviewed-by: Peter Xu
> Cc: "Michael S. Tsirkin"
> Cc: Paolo Bonzini
>
On 09/14/2018 01:46 PM, John Snow wrote:
On 09/13/2018 12:48 PM, Marc Olson wrote:
Are there further thoughts on this patch?
The CI tools may have missed it since it appears to have been sent in
reply to the V1 instead of as a new thread. When you send a revision
out, can you send it as its
On 09/13/2018 12:48 PM, Marc Olson wrote:
> Are there further thoughts on this patch?
>
The CI tools may have missed it since it appears to have been sent in
reply to the V1 instead of as a new thread. When you send a revision
out, can you send it as its own thread?
(We're also in a bit of a
Yes, it's an Nvidia GTX 1060 6GB with PCI passthrough to a Windows 1803
KVM guest. As far as I can tell my setup is very similar to Heiko's,
only I am using libvirt, not qemu directly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On 09/14/2018 01:51 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.09.2018 20:39, John Snow wrote:
>>
>> On 09/10/2018 01:00 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> 10.09.2018 19:55, Eric Blake wrote:
On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> -int64_t
[revisiting this thread]
On 6/29/18 10:43 AM, Kevin Wolf wrote:
Am 29.06.2018 um 17:22 hat Eric Blake geschrieben:
On 06/29/2018 03:44 AM, Kevin Wolf wrote:
Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
Match our code to the spec change in the previous patch - there's
no reason for the
The usb-host devices have the problem.
It does not seem to matter if 1 or all 3 are specified.. I had thought
maybe only one of them was causing the issue.. but all of them are
affected if '-daemonize' is specified at startup.
Correct, the vfio-pci device 1:00.x is an Nvidia GPU+audio, and
When interrupt remapping is enabled, add a special IVHD device
(type IOAPIC).
Signed-off-by: Brijesh Singh
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom Lendacky
Cc: Suravee Suthikulpanit
---
hw/i386/acpi-build.c | 29
Emulate the interrupt remapping support when guest virtual APIC is
not enabled.
For more info Refer: AMD IOMMU spec Rev 3.0 - section 2.2.5.1
When VAPIC is not enabled, it uses interrupt remapping as defined in
Table 20 and Figure 15 from IOMMU spec.
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Currently, the amdvi_validate_dte() assumes that a valid DTE will
always have V=1. This is not true. The V=1 means that bit[127:1] are
valid. A valid DTE can have IV=1 and V=0 (i.e pt=off, intremap=on).
Remove the V=1 check from amdvi_validate_dte(), make the caller
responsible to check for V or
Register the interrupt remapping callback and read/write ops for the
amd-iommu-ir memory region.
amd-iommu-ir is set to higher priority to ensure that this region won't
be masked out by other memory regions.
While at it, add a overlapping amd-iommu region with higher priority
and update address
This series adds the interrupt remapping support for amd-iommu device.
IOMMU spec is available at: https://support.amd.com/TechDocs/48882_IOMMU.pdf
To enable the interrupt remap use below qemu cli
# $QEMU \
-device amd-iommu,intremap=on
I have tested FC-28 and Ubuntu 18.04 guest.
Linux
Now that amd-iommu support interrupt remapping, enable the GASup in IVRS
table and GASup in extended feature register to indicate that IOMMU
support guest virtual APIC mode. GASup provides option to guest OS to
make use of 128-bit IRTE.
Note that the GAMSup is set to zero to indicate that
The vtd_generate_msi_message() in intel-iommu is used to construct a MSI
Message from IRQ. A similar function will be needed when we add interrupt
remapping support in amd-iommu. Moving the function in common file to
avoid the code duplication. Rename it to x86_iommu_irq_to_msi_message().
There is
Interrupt remapping needs kernel-irqchip={off|split} on both Intel and AMD
platforms. Move the check in common place.
Signed-off-by: Brijesh Singh
Reviewed-by: Peter Xu
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Tom
I try to bisect git version. When I run git bisect bad v3.0.0 it says:
Bisecting: 1298 revisions left to test after this (roughly 10 steps)
error: Your local changes to the following files would be overwritten by
checkout:
configure
po/bg.po
po/de_DE.po
po/fr_FR.po
On 9/14/18 12:24 PM, Eric Blake wrote:
On 9/14/18 11:51 AM, Vladimir Sementsov-Ogievskiy wrote:
bitmap_to_extents function is broken: it switches dirty variable after
every iteration, however it can process only part of dirty (or zero)
area during one iteration in case when this area is too
George: Can you confirm how your graphics is setup; the original
reporter had an Nvidia card with PCI passthrough; is yours the same?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1788665
Title:
On 09/14/2018 01:51 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.09.2018 20:39, John Snow wrote:
>>
>> On 09/10/2018 01:00 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> 10.09.2018 19:55, Eric Blake wrote:
On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> -int64_t
14.09.2018 20:39, John Snow wrote:
On 09/10/2018 01:00 PM, Vladimir Sementsov-Ogievskiy wrote:
10.09.2018 19:55, Eric Blake wrote:
On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:
-int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start);
+int64_t hbitmap_next_zero(const HBitmap
On 9/12/18 8:18 AM, Jeff Cody wrote:
When we converted rbd to get rid of the older key/value-centric
encoding format, we broke compatibility with image files with backing
file strings encoded in the old format.
This leaves a bit of an ugly conundrum, and a hacky solution.
+/* Take
14.09.2018 20:35, Eric Blake wrote:
On 9/14/18 12:30 PM, Vladimir Sementsov-Ogievskiy wrote:
while (begin < overall_end && i < nb_extents) {
+ bool next_dirty = !dirty;
+
if (dirty) {
end = bdrv_dirty_bitmap_next_zero(bitmap, begin);
} else {
@@
On 09/10/2018 01:00 PM, Vladimir Sementsov-Ogievskiy wrote:
> 10.09.2018 19:55, Eric Blake wrote:
>> On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
> -int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start);
> +int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t
On 14/09/2018 18:54, Andrew Baumann wrote:
> On the other hand, since these OSes are a decade old (mainstream support
> ended; will drop out of extended support in just over a year from now),
> and you are the first person to report a problem in 1.5 years since the
> patch went in, I wonder if we
On 14/09/2018 19:14, Kevin Wolf wrote:
>> As you mention, you could have a nested aio_poll() in the main thread,
>> for example invoked from a bottom half, but in that case I'd rather
>> track the caller that is creating the bottom half and see if it lacks a
>> bdrv_ref/bdrv_unref (or perhaps it's
14.09.2018 20:30, Vladimir Sementsov-Ogievskiy wrote:
14.09.2018 20:24, Eric Blake wrote:
On 9/14/18 11:51 AM, Vladimir Sementsov-Ogievskiy wrote:
bitmap_to_extents function is broken: it switches dirty variable after
every iteration, however it can process only part of dirty (or zero)
area
On 09/14/2018 11:15 AM, Vladimir Sementsov-Ogievskiy wrote:
> This is a last brick, necessary to play with nbd bitmap export in
> conjunction with image fleecing.
>
> v3:
> 01: fix type in commit message, add John's r-b
> 02: splitted refactoring
> 03: improve commit message, split some
I did a git-bisect between 4.14.18(bad) and 4.14.10(good).
Unsurprisingly, this is the first "bad" commit:
KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL
commit d28b387fb74da95d69d2615732f50cceb38e9a4d
George
--
You received this bug notification because you are a member of qemu-
On 9/14/18 12:30 PM, Vladimir Sementsov-Ogievskiy wrote:
while (begin < overall_end && i < nb_extents) {
+ bool next_dirty = !dirty;
+
if (dirty) {
end = bdrv_dirty_bitmap_next_zero(bitmap, begin);
} else {
@@ -1962,6 +1964,7 @@ static unsigned int
14.09.2018 20:24, Eric Blake wrote:
On 9/14/18 11:51 AM, Vladimir Sementsov-Ogievskiy wrote:
bitmap_to_extents function is broken: it switches dirty variable after
every iteration, however it can process only part of dirty (or zero)
area during one iteration in case when this area is too large
On 9/14/18 11:51 AM, Vladimir Sementsov-Ogievskiy wrote:
bitmap_to_extents function is broken: it switches dirty variable after
every iteration, however it can process only part of dirty (or zero)
area during one iteration in case when this area is too large for one
extent.
Fortunately, the bug
On 09/14/2018 11:15 AM, Vladimir Sementsov-Ogievskiy wrote:
> This is a last brick, necessary to play with nbd bitmap export in
> conjunction with image fleecing.
>
> v3:
> 01: fix type in commit message, add John's r-b
> 02: splitted refactoring
> 03: improve commit message, split some
Am 14.09.2018 um 17:12 hat Paolo Bonzini geschrieben:
> On 13/09/2018 18:59, Kevin Wolf wrote:
> > Am 13.09.2018 um 17:10 hat Paolo Bonzini geschrieben:
> >> On 13/09/2018 14:52, Kevin Wolf wrote:
> >>> + if (qemu_get_current_aio_context() == qemu_get_aio_context()) {
> >>> + /* If we are in the
From: "Dr. David Alan Gilbert"
There's a couple of error paths in qemu_loadvm_state
which happen early on but after we've initialised the
load state; that needs to be cleaned up otherwise
we can hit asserts if the state gets reinitialised later.
Signed-off-by: Dr. David Alan Gilbert
---
From: "Dr. David Alan Gilbert"
This is a pair of related migration fixes for cases where the loadvm
state doesn't get cleaned up.
In the first case this is because the code hasn't cleared the postcopy
flag, and so a following loadvm gets very confused (leading to it
not cleaning up the loadvm
From: "Dr. David Alan Gilbert"
Clear have_listen_thread when we exit the thread.
The fallout from this was that various things thought there was
an ongoing postcopy after the postcopy had finished.
The case that failed was postcopy->savevm->loadvm.
This corresponds to RH bug
Thanks for digging into this Fred, and sorry -- it seems Andrey and I both
missed that subtlety with TryAcquireSRWLockExclusive when we first made this
change.
On the other hand, since these OSes are a decade old (mainstream support ended;
will drop out of extended support in just over a
bitmap_to_extents function is broken: it switches dirty variable after
every iteration, however it can process only part of dirty (or zero)
area during one iteration in case when this area is too large for one
extent.
Fortunately, the bug don't produce wrong extents: it just inserts
zero-length
Am 13.09.2018 um 22:55 hat Max Reitz geschrieben:
> On 13.09.18 14:52, Kevin Wolf wrote:
> > When starting an active commit job, other callbacks can run before
> > mirror_start_job() calls bdrv_ref() where needed and cause the nodes to
> > go away. Add another pair of bdrv_ref/unref() around it to
20.06.2018 21:09, Eric Blake wrote:
On 06/20/2018 12:04 PM, Vladimir Sementsov-Ogievskiy wrote:
20.06.2018 19:27, Eric Blake wrote:
On 06/09/2018 10:17 AM, Vladimir Sementsov-Ogievskiy wrote:
Handle new NBD meta namespace: "qemu", and corresponding queries:
"qemu:dirty-bitmap:".
With new
To clarify, are the problematic USB passthrough devices these:
-device usb-host,vendorid=0x04d9,productid=0x0171 \
-device usb-host,vendorid=0x1532,productid=0x005c \
-device usb-host,vendorid=0x1b1c,productid=0x0c09
or this:
-device vfio-pci,host=04:00.0 \
Without knowing what the vfio-pci
On 14 September 2018 at 16:19, Paolo Bonzini wrote:
> On 14/09/2018 16:00, John Snow wrote:
>>> Maybe not. We can hardly analyze all peripheral devices code and fix all
>>> the calls.
>>> But I think we can improve that patch and at least look through ide core to
>>> fix other calls.
>>>
>>>
On Fri, 14 Sep 2018, Anthony PERARD wrote:
> xend have been replaced by libxenlight (libxl) for many Xen releases
> now.
>
> Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
> ---
> hw/xenpv/xen_machine_pv.c | 2 +-
> include/hw/xen/xen.h | 2 +-
> qemu-options.hx |
On Fri, 14 Sep 2018, Anthony PERARD wrote:
> It is broken since Xen 4.9 [1] and it will not build in Xen 4.12. Also,
> it is not built by default since QEMU 2.6.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00313.html
>
> Signed-off-by: Anthony PERARD
Acked-by:
On 14/09/2018 16:00, John Snow wrote:
>> Maybe not. We can hardly analyze all peripheral devices code and fix all the
>> calls.
>> But I think we can improve that patch and at least look through ide core to
>> fix other calls.
>>
>> Pavel Dovgalyuk
>>
> It just seems odd that if you're working
On 29/08/2018 14:41, Viktor Prutyanov wrote:
> elf2dmp is a converter from ELF dump (produced by 'dump-guest-memory') to
> Windows MEMORY.DMP format (also know as 'Complete Memory Dump') which can be
> opened in WinDbg.
>
> This tool can help if VMCoreInfo device/driver is absent in Windows VM
On Fri, 14 Sep 2018 16:19:07 +0200
Erik Skultety wrote:
> On Fri, Sep 14, 2018 at 12:50:09PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > Also libvirt manages hotpluggability per device *class*, not per device
> > > > *instance*. So a device being hotpluggable or not depending on some
>
New action is like clean action: do the whole thing in .prepare and
undo in .abort. This behavior for bitmap-changing actions is needed
because backup job actions use bitmap in .prepare.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
---
qapi/transaction.json | 2 ++
This is a last brick, necessary to play with nbd bitmap export in
conjunction with image fleecing.
v3:
01: fix type in commit message, add John's r-b
02: splitted refactoring
03: improve commit message, split some refactoring to 02
04: add John's r-b
05: drop extra state variable, make it local
Move checks from qmp_x_block_dirty_bitmap_merge() to
bdrv_merge_dirty_bitmap(), to share them with dirty bitmap merge
transaction action in future commit.
Note: for now, only qmp_x_block_dirty_bitmap_merge() calls
bdrv_merge_dirty_bitmap().
Signed-off-by: Vladimir Sementsov-Ogievskiy
Rename block-dirty-bitmap-clear transaction handlers to reuse them for
x-block-dirty-bitmap-merge transaction in the following patch.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
---
blockdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Use more generic names to reuse the function for bitmap merge in the
following commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block_int.h | 2 +-
block/dirty-bitmap.c | 4 ++--
blockdev.c| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff
Add backup parameter to bdrv_merge_dirty_bitmap() to be used then with
bdrv_restore_dirty_bitmap() if it needed to restore the bitmap after
merge operation.
This is needed to implement bitmap merge transaction action in further
commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
On 13/09/2018 19:21, Kevin Wolf wrote:
> Am 13.09.2018 um 17:11 hat Paolo Bonzini geschrieben:
>> On 13/09/2018 14:52, Kevin Wolf wrote:
>>> Even if AIO_WAIT_WHILE() is called in the home context of the
>>> AioContext, we still want to allow the condition to change depending on
>>> other threads
On 13/09/2018 18:59, Kevin Wolf wrote:
> Am 13.09.2018 um 17:10 hat Paolo Bonzini geschrieben:
>> On 13/09/2018 14:52, Kevin Wolf wrote:
>>> + if (qemu_get_current_aio_context() == qemu_get_aio_context()) {
>>> + /* If we are in the main thread, the callback is allowed to unref
>>> + * the
On 14/09/2018 07:11, Li Qiang wrote:
> Just as other devices do.
>
> Signed-off-by: Li Qiang
> ---
> hw/misc/edu.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/hw/misc/edu.c b/hw/misc/edu.c
> index df26a4d046..0687ffd343 100644
> --- a/hw/misc/edu.c
> +++
On 14/09/2018 16:31, Liran Alon wrote:
>> There is still a problem, however, in that the same input stream would
>> be parsed differently depending on the kernel version. In particular,
>> if in the future the maximum nested state size grows, you break all
>> existing save files.
>
> I’m not
On 9/14/18 3:35 AM, lampahome wrote:
The function qcow2_get_cluster_type() is in /block/qcow2.h
It will return the flage based on the entry.
There're some flags confused me.
What's difference between QCOW2_CLUSTER_ZERO_ALLOC &
QCOW2_CLUSTER_ZERO_PLAIN
in there?
Look at docs/interop/qcow2.txt
On 9/14/18 1:05 AM, Fam Zheng wrote:
On Fri, 09/14 12:23, lampahome wrote:
Can I convert from internap snapshot to external snapshot?
If there's 3 snapshots in one qcow2, can I convert them all to external
snapshots?
Qcow2 doesn't track internal snapshot dependencies like external snapshot,
On 9/13/18 9:19 PM, lampahome wrote:
Sorry, I need to explain what case I want to do
Todo: I want to *backup a block device into qcow2 format image.*
I met a problem which is the *file size limit of filesystem* ex: Max is
16TB for any file in ext4, but the block device maybe 32TB or more.
I
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > OK, so now I've found the bit about the magic 42; commit 7b074a22 of
> > yours; recommended checking for 42 for knowing we had autosuspend;
> > what's actually in the current fedora hid rules is serial!=1 - I wonder
> > what others have.
>
On Thu, 13 Sep 2018 14:20:25 +0200
Igor Mammedov wrote:
> On Wed, 29 Aug 2018 17:36:09 +0200
> David Hildenbrand wrote:
>
> > To factor out plugging and unplugging of memory device we need access to
> > the memory region. So let's replace get_region_size() by
> > get_memory_region().
this part
> On 14 Sep 2018, at 13:59, Paolo Bonzini wrote:
>
> On 14/09/2018 11:54, Liran Alon wrote:
>>> On 14/09/2018 09:16, Paolo Bonzini wrote:
>>> Heh, I was going to send a similar patch. However, things are a bit
>>> more complex for two reason.
>>>
>>> First, I'd prefer to reuse the hflags and
On 9/13/18 10:58 PM, lampahome wrote:
In general case, what's difference between internal and external snapshot?
You may find my KVM forum presentation from 2015 useful:
http://events17.linuxfoundation.org/sites/events/files/slides/2015-qcow2-expanded.pdf
Internal snapshots use reference
On Fri, Sep 14, 2018 at 12:50:09PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Also libvirt manages hotpluggability per device *class*, not per device
> > > *instance*. So a device being hotpluggable or not depending on some
> > > device property is a problem for libvirt ...
> > >
> > > I'm open
On 09/14/2018 03:27 AM, Pavel Dovgalyuk wrote:
>> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru]
>>> From: John Snow [mailto:js...@redhat.com]
>>> On 09/12/2018 04:19 AM, Pavel Dovgalyuk wrote:
This patch makes IDE trim BH deterministic, because it affects
the device state.
11.09.2018 22:45, John Snow wrote:
On 07/06/2018 07:36 AM, Vladimir Sementsov-Ogievskiy wrote:
New action is like clean action: do the whole thing in .prepare and
undo in .abort. This behavior for bitmap-changing actions is needed
because backup job actions use bitmap in .prepare.
On 9/13/18 7:58 PM, Zhang Chen wrote:
Signed-off-by: zhanghailiang
Signed-off-by: Zhang Chen
Signed-off-by: Zhang Chen
Should both of these last two S-o-b be present?
Maybe it will be more convenient to contact me, I use both of the email. :)
I can't tell you it's wrong, only that it
On 09/14/2018 01:48 AM, Pavel Dovgalyuk wrote:
>> From: John Snow [mailto:js...@redhat.com]
>> On 09/12/2018 04:19 AM, Pavel Dovgalyuk wrote:
>>> This patch makes IDE trim BH deterministic, because it affects
>>> the device state. Therefore its invocation should be replayed
>>> instead of
As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
review, let's define a common set of backend conventions to help with
management layer implementation, and interoperability.
v2:
- drop --pidfile
- add some notes about daemonizing & stdin/out/err
Cc: libvir-l...@redhat.com
Cc:
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Friday, September 14, 2018 8:45 PM
> To: liujunjie (A) ; m...@redhat.com
> Cc: Huangweidong (C) ; wangxin (U)
> ; qemu-devel@nongnu.org; Gonglei (Arei)
> ; Zhoujian (jay)
> Subject: Re: [Qemu-devel] [PATCH]
On 09/13/2018 02:24 PM, Halil Pasic wrote:
On 09/13/2018 07:15 PM, Tony Krowiak wrote:
On 09/13/2018 01:02 PM, Tony Krowiak wrote:
On 09/13/2018 02:29 AM, Christian Borntraeger wrote:
On 09/13/2018 07:48 AM, Thomas Huth wrote:
On 2018-09-12 22:08, Tony Krowiak wrote:
From: Tony Krowiak
-20180914
for you to fetch changes up to d3228ed3829981047138bbaff332026f9d64f337:
seccomp: check TSYNC host capability (2018-09-14 15:01:55 +0200)
pull-seccomp-20180914
From: Marc-André Lureau
Remove -sandbox option if the host is not capable of TSYNC, since the
sandbox will fail at setup time otherwise. This will help libvirt, for
ex, to figure out if -sandbox will work.
Signed-off-by: Marc-André Lureau
Acked-by: Eduardo Otubo
---
qemu-seccomp.c | 19
Hi,
> OK, so now I've found the bit about the magic 42; commit 7b074a22 of
> yours; recommended checking for 42 for knowing we had autosuspend;
> what's actually in the current fedora hid rules is serial!=1 - I wonder
> what others have.
Whatever upstream systemd/udev has I guess ...
A bit of
On 2018年09月08日 21:04, liujunjie wrote:
Before, we did not clear callback like handle_output when delete
the virtqueue which may result be segmentfault.
The scene is as follows:
1. Start a vm with multiqueue vhost-net,
2. then we write VIRTIO_PCI_GUEST_FEATURES in PCI configuration to
triger
Hi
On Fri, Sep 14, 2018 at 2:55 PM, Gerd Hoffmann wrote:
> Hi,
>
>> +* --pidfile=PATH
>> +
>> +Write the process id (PID) to the given file PATH. This is mostly
>> +useful if the backend daemonize/fork itself.
>
> Is there any reason to daemonize itself?
>
> If not: shoud we disallow it and
ping
> -Original Message-
> From: liujunjie (A)
> Sent: Saturday, September 08, 2018 9:05 PM
> To: m...@redhat.com; jasow...@redhat.com
> Cc: wangxin (U) ; Zhoujian (jay)
> ; Gonglei (Arei) ;
> Huangweidong (C) ; qemu-devel@nongnu.org;
> liujunjie (A)
> Subject: [PATCH] clean up callback
>
> > Hi Luiz,
> >
> > Thanks for the review.
> >
> > >
> > > > This patch adds virtio-pmem driver for KVM guest.
> > > >
> > > > Guest reads the persistent memory range information from
> > > > Qemu over VIRTIO and registers it on nvdimm_bus. It also
> > > > creates a nd_region object
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Windows guests have trouble dealing with usb devices having identical
> serial numbers. So, assign unique serial numbers to usb hid devices.
> All other usb devices have this already.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/hw/compat.h | 14
xend have been replaced by libxenlight (libxl) for many Xen releases
now.
Signed-off-by: Anthony PERARD
---
hw/xenpv/xen_machine_pv.c | 2 +-
include/hw/xen/xen.h | 2 +-
qemu-options.hx | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git
See first patch description.
Anthony PERARD (2):
Remove broken Xen PV domain builder
xen: Replace few mentions of xend by libxl
configure | 17 --
hw/xenpv/Makefile.objs | 2 -
hw/xenpv/xen_domainbuild.c | 299
It is broken since Xen 4.9 [1] and it will not build in Xen 4.12. Also,
it is not built by default since QEMU 2.6.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00313.html
Signed-off-by: Anthony PERARD
---
configure | 17 --
hw/xenpv/Makefile.objs
Ok finally got it,
The SRWL API seems to be available since Vista and Server 2008
except the 'TryAcquireSRWLockExclusive' function which is
available starting Seven and Server 2008 *R2*. Hence the error
message.
So basically that means QEMU is not compatible with version older
than Seven or
On 14/09/2018 11:54, Liran Alon wrote:
>> On 14/09/2018 09:16, Paolo Bonzini wrote:
>> Heh, I was going to send a similar patch. However, things are a bit
>> more complex for two reason.
>>
>> First, I'd prefer to reuse the hflags and hflags2 fields that we already
>> have, and only store the
* Gerd Hoffmann (kra...@redhat.com) wrote:
> > > +[STR_SERIAL_MOUSE] = "89126",
> > > +[STR_SERIAL_TABLET]= "28754",
> > > +[STR_SERIAL_KEYBOARD] = "68284",
> >
> > Is there any significance to the magical numbers?
>
> No, other than that the three device types should have
Hi,
> +* --pidfile=PATH
> +
> +Write the process id (PID) to the given file PATH. This is mostly
> +useful if the backend daemonize/fork itself.
Is there any reason to daemonize itself?
If not: shoud we disallow it and drop the --pidfile switch?
If yes: should we add a --daemonize switch
Hi,
> > Also libvirt manages hotpluggability per device *class*, not per device
> > *instance*. So a device being hotpluggable or not depending on some
> > device property is a problem for libvirt ...
> >
> > I'm open to suggestions how to handle this better, as long as the
> > libvirt people
Windows guests have trouble dealing with usb devices having identical
serial numbers. So, assign unique serial numbers to usb hid devices.
All other usb devices have this already.
Signed-off-by: Gerd Hoffmann
---
include/hw/compat.h | 14 +-
hw/usb/dev-hid.c| 24
> > +[STR_SERIAL_MOUSE] = "89126",
> > +[STR_SERIAL_TABLET]= "28754",
> > +[STR_SERIAL_KEYBOARD] = "68284",
>
> Is there any significance to the magical numbers?
No, other than that the three device types should have different ones.
> Will this change trigger a serial
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Windows guests have trouble dealing with usb devices having identical
> serial numbers. So, assign unique serial numbers to usb hid devices.
> All other usb devices have this already.
>
> Signed-off-by: Gerd Hoffmann
OK, so that's part of
Yes I could, but it rebuilds too long. I will report results later, when
find broke commit.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1792193
Title:
AMD Athlon(tm) X2 Dual-Core QL-64 bug
Windows guests have trouble dealing with usb devices having identical
serial numbers. So, assign unique serial numbers to usb hid devices.
All other usb devices have this already.
Signed-off-by: Gerd Hoffmann
---
hw/usb/dev-hid.c | 24 +---
1 file changed, 13 insertions(+),
The sslverify setting is supposed to turn off all TLS certificate
checks in libcurl. However because of the way we use it, it only
turns off peer certificate authenticity checks
(CURLOPT_SSL_VERIFYPEER). This patch makes it also turn off the check
that the server name in the certificate is the
>On 14/09/2018 09:16, Paolo Bonzini wrote:
>Heh, I was going to send a similar patch. However, things are a bit
>more complex for two reason.
>
>First, I'd prefer to reuse the hflags and hflags2 fields that we already
>have, and only store the VMCS blob in the subsection. For example,
On Thu, Sep 13, 2018 at 5:30 PM Mark Cave-Ayland
wrote:
>
> On 13/09/18 15:21, Artyom Tarasenko wrote:
>
> > On Sat, Sep 8, 2018 at 11:11 AM Mark Cave-Ayland
> > wrote:
> >>
> >> Whilst the PReP specification describes how all PCI IRQs are routed via IRQ
> >> 15 on the interrupt controller, the
The function qcow2_get_cluster_type() is in /block/qcow2.h
It will return the flage based on the entry.
There're some flags confused me.
What's difference between QCOW2_CLUSTER_ZERO_ALLOC &
QCOW2_CLUSTER_ZERO_PLAIN
in there?
Le 09/13/2018 à 07:29 PM, Andrew Baumann a écrit :
Does this crash always happen at startup? Is it deterministic?
Hi Andrew,
Thanks for your reactivity! Yes it crashes all the time..
c135 is STATUS_DLL_NOT_FOUND. I suspect ntdll is trying to demand-load
another DLL to provide
1 - 100 of 117 matches
Mail list logo
