Hi,
I have some dumb questions about this Red Hat cross version migration
support matrix:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-kvm_live_migration-live_migration_and_red_hat_enterprise_linux_version_comp
On Tue, Dec 12, 2017 at 08:51:13AM +0800, Fam Zheng wrote:
> Signed-off-by: Fam Zheng
>
> ---
>
> v4: "images". [Kevin]
>
> v3: Document that the option is not allowed for read-write. [Stefan]
>
> v2: - "code{qemu-img}". [Kashyap, Eric]
> - "etc.." -> "etc.".
> ---
> qemu-img.texi | 9 +++
On Mon, 11 Dec 2017 21:32:58 +0100
David Hildenbrand wrote:
> On 11.12.2017 19:01, Cornelia Huck wrote:
> > On Mon, 11 Dec 2017 14:47:34 +0100
> > David Hildenbrand wrote:
> >
> >> Use s390_cpu_virt_mem_write() so we can actually revert what we did
> >> (re-inject the dequeued IO interrupt).
On Mon, Dec 11, 2017 at 09:16:23AM -0600, Mark Kanda wrote:
> v2: add check for maximum queue size [Stefan]
>
> This series is for two minor virtio-blk changes. The first patch
> makes the virtio-blk queue size user configurable. The second patch
> rejects logical block size > physical block confi
On Mon, 11 Dec 2017 21:34:20 +0100
David Hildenbrand wrote:
> On 11.12.2017 18:17, Cornelia Huck wrote:
> > On Mon, 11 Dec 2017 14:47:29 +0100
> > David Hildenbrand wrote:
> >
> >> This makes it clearer, which device is used for which accelerator.
> >>
> >> Signed-off-by: David Hildenbrand
>
On Mon, Dec 11, 2017 at 07:51:43AM -0600, Eric Blake wrote:
> On 12/11/2017 04:16 AM, Stefan Hajnoczi wrote:
>
> >>> I don't understand the need for the qemu_lock_guard_is_taken(&name)
> >>> condition, why not do the following?
> >>>
> >>> for (QEMU_LOCK_GUARD(type, name, lock);
> >>>;
>
On 12.12.2017 10:15, Cornelia Huck wrote:
> On Mon, 11 Dec 2017 21:34:20 +0100
> David Hildenbrand wrote:
>
>> On 11.12.2017 18:17, Cornelia Huck wrote:
>>> On Mon, 11 Dec 2017 14:47:29 +0100
>>> David Hildenbrand wrote:
>>>
This makes it clearer, which device is used for which accelerat
On Tue, Dec 12, 2017 at 08:51:13AM +0800, Fam Zheng wrote:
> Signed-off-by: Fam Zheng
[...]
> qemu-img.texi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/qemu-img.texi b/qemu-img.texi
> index fdcf120f36..d93501f94f 100644
> --- a/qemu-img.texi
> +++ b/qemu-img.texi
> @@ -57
* Gaurav Poothia (gaurav.poot...@gmail.com) wrote:
> Hi,
> I have some dumb questions about this Red Hat cross version migration
> support matrix:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-kvm_live_migrati
On Mon, Dec 11, 2017 at 01:53:40PM +, Wang, Wei W wrote:
> On Monday, December 11, 2017 7:12 PM, Stefan Hajnoczi wrote:
> > On Sat, Dec 09, 2017 at 04:23:17PM +, Wang, Wei W wrote:
> > > On Friday, December 8, 2017 4:34 PM, Stefan Hajnoczi wrote:
> > > > On Fri, Dec 8, 2017 at 6:43 AM, Wei
On Tue, Dec 12, 2017 at 01:25:30AM +, Liu, Changpeng wrote:
> > The vhost-blk code should also check that
> > hdev->vhost_ops->vhost_set_config != NULL during realize. This way
> > users see the error when adding the device instead of at runtime when
> > the function gets called.
> For vhost-b
On Tue, 12 Dec 2017 00:50:51 +0100
Paolo Bonzini wrote:
> On 11/12/2017 20:46, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Iterate through an address space calling a function for each
> > section. The iteration is done in order.
> >
> > Signed-off-by: Dr. Da
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 11/12/2017 20:46, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Iterate through an address space calling a function for each
> > section. The iteration is done in order.
> >
> > Signed-off-by: Dr. David Alan Gilb
On Tue, 12 Dec 2017 10:58:12 +0100
David Hildenbrand wrote:
> On 12.12.2017 10:15, Cornelia Huck wrote:
> > On Mon, 11 Dec 2017 21:34:20 +0100
> > David Hildenbrand wrote:
> >
> >> On 11.12.2017 18:17, Cornelia Huck wrote:
> >>> On Mon, 11 Dec 2017 14:47:29 +0100
> >>> David Hildenbrand wr
On 12 December 2017 at 02:48, Peter Xu wrote:
> On Mon, Dec 11, 2017 at 08:55:56PM +, Peter Maydell wrote:
>> On 11 December 2017 at 19:42, Emilio G. Cota wrote:
>> > On Mon, Dec 11, 2017 at 17:32:48 +, Peter Maydell wrote:
>> >> Thanks. I think I have come down on the side of putting thi
On 12 December 2017 at 05:55, Shannon Zhao wrote:
> On 2017/12/8 23:02, Peter Maydell wrote:
>> Currently we only provide one non-secure UART on the virt
>> board. This is OK for most purposes, but there are some
>> use cases where having a second UART would be useful (like
>> bare-metal testing w
On 12.12.2017 10:15, Cornelia Huck wrote:
> On Mon, 11 Dec 2017 21:34:20 +0100
> David Hildenbrand wrote:
>
>> On 11.12.2017 18:17, Cornelia Huck wrote:
>>> On Mon, 11 Dec 2017 14:47:29 +0100
>>> David Hildenbrand wrote:
>>>
This makes it clearer, which device is used for which accelerat
On 12/12/2017 11:31, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>> On 11/12/2017 20:46, Dr. David Alan Gilbert (git) wrote:
>>> From: "Dr. David Alan Gilbert"
>>>
>>> Iterate through an address space calling a function for each
>>> section. The iteration is done
>
> Do we want to switch to the same pattern for the storage attribute
> device as well?
>
Unfortunately not that easy due to the KVM capability check. Will leave
it as is for now.
> Change looks fine to me.
>
--
Thanks,
David / dhildenb
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 12/12/2017 11:31, Dr. David Alan Gilbert wrote:
> > * Paolo Bonzini (pbonz...@redhat.com) wrote:
> >> On 11/12/2017 20:46, Dr. David Alan Gilbert (git) wrote:
> >>> From: "Dr. David Alan Gilbert"
> >>>
> >>> Iterate through an address space calling
On 12/12/17 06:53, Shannon Zhao wrote:
>
>
> On 2017/12/8 23:02, Peter Maydell wrote:
>> Add the second UART to the ACPI tables.
>>
>> Signed-off-by: Peter Maydell
>> ---
>> Pure guesswork, as I don't have a UEFI setup to hand and
>> am not familiar with ACPI table formats either...
>> ---
>> h
On 12 December 2017 at 11:06, Laszlo Ersek wrote:
> BTW, has anyone tested this with the ArmVirtQemu firmware? As far as I
> can see from the firmware code, the firmware will use the PL011 whose
> description comes first in the DTB (and ignore the other PL011), in an
> fdt_next_node() traversal. I
When listening on unix/tcp sockets there was optional code that would update
the original SocketAddress struct with the info about the actual address that
was listened on. Since the conversion of everything to QIOChannelSocket, no
remaining caller made use of this feature. It has been replaced with
Am 11.12.2017 um 19:40 hat John Snow geschrieben:
>
>
> On 12/11/2017 06:15 AM, Kevin Wolf wrote:
> > Am 09.12.2017 um 01:57 hat John Snow geschrieben:
> >> Here's an idea of what this API might look like without revealing
> >> explicit merge/split primitives.
> >>
> >> A new bitmap property that
On 12/12/2017 12:03, Dr. David Alan Gilbert wrote:
>> nop means that attributes (readonly, romd_mode, mr+offset_in_region)
>> haven't changed; nop is optionally followed by log_start or log_stop.
>> If any of them changes, you get del+add (del is always before add).
>>
>>> Th nice thing we have her
On 12/12/17 12:11, Peter Maydell wrote:
> On 12 December 2017 at 11:06, Laszlo Ersek wrote:
>> BTW, has anyone tested this with the ArmVirtQemu firmware? As far as I
>> can see from the firmware code, the firmware will use the PL011 whose
>> description comes first in the DTB (and ignore the other
The GTK 3.0 release was made in Feb, 2011:
https://blog.gtk.org/2011/02/10/gtk-3-0-released/
That will soon be 7 years ago, which is enough time to consider
the 3.x series widely supported.
Thus we deprecate the GTK 2.x support, which will allow us to
delete it in the last release of 2018. By
On Tue, Dec 12, 2017 at 11:34:40AM +, Daniel P. Berrange wrote:
> The GTK 3.0 release was made in Feb, 2011:
>
> https://blog.gtk.org/2011/02/10/gtk-3-0-released/
>
> That will soon be 7 years ago, which is enough time to consider
> the 3.x series widely supported.
>
> Thus we deprecate th
On 12 December 2017 at 11:33, Laszlo Ersek wrote:
> On 12/12/17 12:11, Peter Maydell wrote:
>> On 12 December 2017 at 11:06, Laszlo Ersek wrote:
>>> BTW, has anyone tested this with the ArmVirtQemu firmware? As far as I
>>> can see from the firmware code, the firmware will use the PL011 whose
>>>
On Tue, 12 Dec 2017 11:45:22 +0100
David Hildenbrand wrote:
> This is what it looks like now:
>
> commit dec1ff5cfc72fa0998e28a25dd23f0695ddfe21b
> Author: David Hildenbrand
> Date: Mon Nov 13 23:09:56 2017 +0100
>
> s390x/flic: simplify flic initialization
>
> This makes it cle
On 12/12/17 12:44, Ard Biesheuvel wrote:
> On 12 December 2017 at 11:33, Laszlo Ersek wrote:
>> On 12/12/17 12:11, Peter Maydell wrote:
>>> On 12 December 2017 at 11:06, Laszlo Ersek wrote:
BTW, has anyone tested this with the ArmVirtQemu firmware? As far as I
can see from the firmware
On 12 December 2017 at 11:59, Laszlo Ersek wrote:
> Peter, what is the intended use of the second UART?
Per the commit message:
# there are some
# use cases where having a second UART would be useful (like
# bare-metal testing where you don't really want to have to
# probe and set up a PCI device
Refactor disas_thumb2_insn() so that it generates the code for raising
an UNDEF exception for invalid insns, rather than returning a flag
which the caller must check to see if it needs to generate the UNDEF
code. This brings the function in to line with the behaviour of
disas_thumb_insn() and disas
From: Matthew Wilcox
The eXtensible Bitmap is a sparse bitmap representation which is
efficient for set bits which tend to cluster. It supports up to
'unsigned long' worth of bits, and this commit adds the bare bones --
xb_set_bit(), xb_clear_bit() and xb_test_bit().
Signed-off-by: Wei Wang
Cc
Add a new feature, VIRTIO_BALLOON_F_SG, which enables the transfer of
balloon (i.e. inflated/deflated) pages using scatter-gather lists to the
host.
The implementation of the previous virtio-balloon is not very efficient,
because the balloon pages are transferred to the host by one array each
time
This patch series enhances the existing virtio-balloon with the following
new features:
1) fast ballooning: transfer ballooned pages between the guest and host in
chunks using sgs, instead of one array each time; and
2) free page block reporting: a new virtqueue to report guest free pages
to the ho
Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
support of reporting hints of guest free pages to host via virtio-balloon.
Host requests the guest to report free pages by sending a new cmd
id to the guest via the free_page_report_cmd_id configuration register.
When the gues
This patch adds support to find next 1 or 0 bit in a xbmitmap range and
clear a range of bits.
More possible optimizations to add in the future:
1) xb_set_bit_range: set a range of bits.
2) when searching a bit, if the bit is not found in the slot, move on to
the next slot directly.
3) add tags to
This patch made some changes to the original xbitmap implementation from
the linux-dax tree:
- remove xb_fill() and xb_zero() from xbitmap.h since they are not
implemented;
- xb_test_bit: changed "ebit > BITS_PER_LONG" to "ebit >= BITS_PER_LONG",
because bit 64 beyonds the "unsigned long" exc
This patch adds support to walk through the free page blocks in the
system and report them via a callback function. Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages.
One use example of this
The guest free pages should not be discarded by the live migration thread
when page poisoning is enabled with PAGE_POISONING_NO_SANITY=n, because
skipping the transfer of such poisoned free pages will trigger false
positive when new pages are allocated and checked on the destination.
This patch add
On 12/11/2017 09:24 PM, Michael S. Tsirkin wrote:
On Mon, Dec 11, 2017 at 02:38:45PM +0800, Wei Wang wrote:
On 12/01/2017 11:49 PM, Michael S. Tsirkin wrote:
On Wed, Nov 29, 2017 at 09:55:26PM +0800, Wei Wang wrote:
The guest free pages should not be discarded by the live migration thread
when
On 12/12/17 13:07, Peter Maydell wrote:
> On 12 December 2017 at 11:59, Laszlo Ersek wrote:
>> Peter, what is the intended use of the second UART?
>
> Per the commit message:
> # there are some
> # use cases where having a second UART would be useful (like
> # bare-metal testing where you don't r
On 12 December 2017 at 12:41, Laszlo Ersek wrote:
> I agree. There's one user-visible complication: while with one UART,
> it's not possible to mix things up, with two UARTs, users will
> inevitably want to assign inverse roles to them, relative to what QEMU /
> the firmware assigns originally.
>
Am 12.12.2017 um 01:51 hat Fam Zheng geschrieben:
> Signed-off-by: Fam Zheng
>
> ---
>
> v4: "images". [Kevin]
>
> v3: Document that the option is not allowed for read-write. [Stefan]
>
> v2: - "code{qemu-img}". [Kashyap, Eric]
> - "etc.." -> "etc.".
> ---
> qemu-img.texi | 9 +
>
Wei Wang wrote:
> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long
> end)
> +{
> + struct radix_tree_root *root = &xb->xbrt;
> + struct radix_tree_node *node;
> + void **slot;
> + struct ida_bitmap *bitmap;
> + unsigned int nbits;
> +
> + for (; st
On 12/12/17 13:47, Peter Maydell wrote:
> On 12 December 2017 at 12:41, Laszlo Ersek wrote:
>> I agree. There's one user-visible complication: while with one UART,
>> it's not possible to mix things up, with two UARTs, users will
>> inevitably want to assign inverse roles to them, relative to what
On 12/12/2017 7:36, Yoni Bettan wrote:
* according to Eduardo Habkost's commit
fd3b02c8896d597dd8b9e053dec579cf0386aee1
* since all PCIEs now implement INTERFACE_PCIE_DEVICE we
don't need this field anymore
* Devices that where only INTERFACE_PCI
Commit 15afd94a047 added code to acquire and release the AioContext in
qemuio_command(). This means that the lock is taken twice now in the
call path from hmp_qemu_io(). This causes BDRV_POLL_WHILE() to hang for
any requests issued to nodes in a non-mainloop AioContext.
Dropping the first locking
On Mon, 11 Dec 2017 14:47:31 +0100
David Hildenbrand wrote:
> Let the flic device handle it internally. This will allow us to later
> on store floating interrupts in the flic for the TCG case.
>
> This now also simplifies kvm.c. All that's left is the fallback
> interface for floating interrupts
I am going to reanimate works under this QMP/HMP. First of all, it
could be meaningful to settle what output would provide the QMP. I would
like to suggest the following description:
##
# @VirtioFeature:
##
{
'struct': 'VirtioFeature',
'data': {
'name': 'str',
'acked': 'boo
From: "Dr. David Alan Gilbert"
Mostly just manual conversion with very minor fixes.
Signed-off-by: Dr. David Alan Gilbert
---
docs/devel/{migration.txt => migration.rst} | 326 +++-
1 file changed, 176 insertions(+), 150 deletions(-)
rename docs/devel/{migration.txt =>
On 12 December 2017 at 13:28, Laszlo Ersek wrote:
> On 12/12/17 13:47, Peter Maydell wrote:
>> On 12 December 2017 at 12:41, Laszlo Ersek wrote:
>>> I agree. There's one user-visible complication: while with one UART,
>>> it's not possible to mix things up, with two UARTs, users will
>>> inevitab
On Tue, Dec 12, 2017 at 11:12:19AM +, Daniel P. Berrange wrote:
> When listening on unix/tcp sockets there was optional code that would update
> the original SocketAddress struct with the info about the actual address that
> was listened on. Since the conversion of everything to QIOChannelSocke
This is a followup to
v1: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02047.html
v2: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02471.html
v3: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02517.html
v4: https://lists.nongnu.org/archive/html/q
The x_keycode_to_pc_keycode and evdev_keycode_to_pc_keycode
tables are replaced with automatically generated tables.
In addition the X11 heuristics are improved to detect running
on XQuartz and XWin X11 servers, to activate the correct OS-X
and Win32 keycode maps.
Signed-off-by: Daniel P. Berrange
* Dong Jia Shi [2017-12-05 15:43:00 +0800]:
> * Cornelia Huck [2017-12-04 17:11:24 +0100]:
>
> [...]
>
> This one looks good to me too, so:
> Reviewed-by: Dong Jia Shi
>
> >
> > (...)
> >
> > > > Looks sane. We should put a note into the 2.12 changelog as well.
> > > >
> > >
> > > I ag
It is a reserved value and doesn't have a corresponding
valid scancode.
Signed-off-by: Daniel P. Berrange
---
ui/gtk.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 89cc81b708..687560b963 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -1206,6 +1206,12 @@ static gbo
The SDL2 scancodes are conveniently identical to the USB
scancodes. Replace the sdl2_scancode_to_qcode table with
an automatically generated table.
Missing entries in sdl2_scancode_to_qcode now fixed:
- 0x32 -> Q_KEY_CODE_BACKSLASH
- 0x66 -> Q_KEY_CODE_POWER
- 0x67 -> Q_KEY_CODE_KP_EQUALS
Versions of GTK prior to 3.22 did not correctly set the keyval
field when VK_PAUSE was received on Windows.
Signed-off-by: Daniel P. Berrange
---
ui/gtk.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 74df44..89cc81b708 100644
--- a/ui/gtk.c
+++ b/ui/gtk
On 11/12/2017 15:51, Samuel Thibault wrote:
>> Is magic clamping desirable, or is it better to make it a hard error if
>> the user configured a size that is not possible?
> The thing is: the user didn't configure something, she just happened to
> use a braille device bigger than 84 to display qemu'
Replace the scancode2linux table with an automatically
generated table. In doing so, the XenFB keyboard
handler is also converted to the modern InputEvent
framework.
Signed-off-by: Daniel P. Berrange
---
hw/display/xenfb.c | 138 +
1 file chang
This is a followup to
v1: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02047.html
v2: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02471.html
v3: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02517.html
v4: https://lists.nongnu.org/archive/html/q
On Tue, Dec 12, 2017 at 02:28:51PM +0100, Laszlo Ersek wrote:
> On 12/12/17 13:47, Peter Maydell wrote:
> > On 12 December 2017 at 12:41, Laszlo Ersek wrote:
> >> I agree. There's one user-visible complication: while with one UART,
> >> it's not possible to mix things up, with two UARTs, users wil
Replace the keymap_qcode table with automatically generated
tables.
Missing entries in keymap_qcode now fixed:
Q_KEY_CODE_ASTERISK -> KEY_KPASTERISK
Q_KEY_CODE_KP_MULTIPLY -> KEY_KPASTERISK
Q_KEY_CODE_STOP -> KEY_STOP
Q_KEY_CODE_AGAIN -> KEY_AGAIN
Q_KEY_CODE_PROPS -> KEY_PROPS
Q_KEY_C
On 12 December 2017 at 14:10, Peter Maydell wrote:
> On 12 December 2017 at 13:56, Ard Biesheuvel
> wrote:
>> Given that the DEBUG output is only produced on DEBUG builds, couldn't
>> we simply stipulate that DEBUG output appears on the PL011 with the
>> lowest physical address? That keeps the c
On 12 December 2017 at 13:56, Ard Biesheuvel wrote:
> Given that the DEBUG output is only produced on DEBUG builds, couldn't
> we simply stipulate that DEBUG output appears on the PL011 with the
> lowest physical address? That keeps the current status quo, and is
> probably sufficient for 99% of t
Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
and qcode_to_keycode_set3 tables with automatically
generated tables.
Missing entries in qcode_to_keycode_set1 now fixed:
- Q_KEY_CODE_SYSRQ -> 0x54
- Q_KEY_CODE_PRINT -> 0x54 (NB ignored due to special case)
- Q_KEY_CODE_AGAIN -> 0xe00
On 12 December 2017 at 14:12, Ard Biesheuvel wrote:
> On 12 December 2017 at 14:10, Peter Maydell wrote:
>> That doesn't actually usefully separate debug output from the
>> console, though, because stdout-path is also going to point
>> to the UART with the lowest physical address...
>>
>
> By def
Replace the qcode_to_keycode table with automatically
generated tables.
Missing entries in qcode_to_keycode now fixed:
- Q_KEY_CODE_KP_COMMA -> 0x2d
Signed-off-by: Daniel P. Berrange
---
Makefile | 1 +
hw/char/escc.c | 126 +++--
On 12/12/2017 02:49 PM, Cornelia Huck wrote:
> On Mon, 11 Dec 2017 14:47:31 +0100
> David Hildenbrand wrote:
>
>> Let the flic device handle it internally. This will allow us to later
>> on store floating interrupts in the flic for the TCG case.
>>
>> This now also simplifies kvm.c. All that's
On Tue, Dec 12, 2017 at 01:56:44PM +, Ard Biesheuvel wrote:
> On 12 December 2017 at 13:28, Laszlo Ersek wrote:
> > On 12/12/17 13:47, Peter Maydell wrote:
> >> On 12 December 2017 at 12:41, Laszlo Ersek wrote:
> >>> I agree. There's one user-visible complication: while with one UART,
> >>> i
On 12 December 2017 at 14:13, Peter Maydell wrote:
> On 12 December 2017 at 14:12, Ard Biesheuvel
> wrote:
>> On 12 December 2017 at 14:10, Peter Maydell wrote:
>>> That doesn't actually usefully separate debug output from the
>>> console, though, because stdout-path is also going to point
>>>
The current docs for TLS assume only VNC is using TLS. Some of the information
is also outdated (ie lacking subject alt name info for certs). Rewrite it to
more accurately reflect the current situation.
Signed-off-by: Daniel P. Berrange
---
Changed in v2:
- Misc typos (Eric)
qemu-doc.texi |
On 12 December 2017 at 14:16, Ard Biesheuvel wrote:
> On 12 December 2017 at 14:13, Peter Maydell wrote:
>> On 12 December 2017 at 14:12, Ard Biesheuvel
>> wrote:
>>> On 12 December 2017 at 14:10, Peter Maydell
>>> wrote:
That doesn't actually usefully separate debug output from the
On Fri, Dec 08, 2017 at 10:16:50AM -0600, Eric Blake wrote:
> On 12/08/2017 05:58 AM, Daniel P. Berrange wrote:
> > The current docs for TLS assume only VNC is using TLS. Some of the
> > information
> > is also outdated (ie lacking subject alt name info for certs). Rewrite it to
> > more accuratel
On Tue, 12 Dec 2017 22:05:24 +0800
Dong Jia Shi wrote:
> * Dong Jia Shi [2017-12-05 15:43:00 +0800]:
>
> > * Cornelia Huck [2017-12-04 17:11:24 +0100]:
> >
> > [...]
> >
> > This one looks good to me too, so:
> > Reviewed-by: Dong Jia Shi
> >
> > >
> > > (...)
> > >
> > > > > Looks s
This is a followup to
v1: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02047.html
v2: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02471.html
v3: https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg02517.html
v4: https://lists.nongnu.org/archive/html/q
In case it's of direct interest in this thread, the ARM results on
https://www.wireguard.com/build-status/ are running on a QEMU built
with this disgusting cludge: https://א.cc/roJ0gMw3
The patch of this thread is the actually correct way of accomplishing
what that cludge does.
Replace the qcode_to_adb_keycode table with automatically
generated tables.
Missing entries in qcode_to_adb_keycode now fixed:
- Q_KEY_CODE_KP_COMMA -> 0x47
Signed-off-by: Daniel P. Berrange
---
Makefile| 1 +
hw/input/adb.c | 124 +--
Replace the mac_to_qkeycode_map table with automatically
generated table.
Signed-off-by: Daniel P. Berrange
---
Makefile | 1 +
include/ui/input.h | 3 ++
ui/cocoa.m | 129 +
ui/input-keymap.c | 1 +
4 files changed, 7
On Tue, 12 Dec 2017 15:13:46 +0100
Christian Borntraeger wrote:
> On 12/12/2017 02:49 PM, Cornelia Huck wrote:
> > One thing I noticed: You removed the caching of the flic (in the old
> > kvm inject routine), and you generally do more qom invocations (first,
> > to find the common flic; then, to
On 12 December 2017 at 14:17, Peter Maydell wrote:
> On 12 December 2017 at 14:16, Ard Biesheuvel
> wrote:
>> On 12 December 2017 at 14:13, Peter Maydell wrote:
>>> On 12 December 2017 at 14:12, Ard Biesheuvel
>>> wrote:
On 12 December 2017 at 14:10, Peter Maydell
wrote:
> Tha
On Sun, Dec 10, 2017 at 02:10:41AM -0500, Programmingkid wrote:
> On Macintosh keyboards there is a key called fn that is used to give the
> function keys more functionality. Does this key exist in the keyboard keys
> database?
When you say "Macintosh keyboards" are you talking about the old style
On Fri, Dec 08, 2017 at 03:02:06PM +, Peter Maydell wrote:
> Add virt-2.12 machine type.
>
> Signed-off-by: Peter Maydell
> ---
> include/hw/compat.h | 3 +++
> hw/arm/virt.c | 19 +--
> 2 files changed, 20 insertions(+), 2 deletions(-)
Reviewed-by: Andrew Jones
>
On Fri, Dec 08, 2017 at 03:02:07PM +, Peter Maydell wrote:
> Currently we only provide one non-secure UART on the virt
> board. This is OK for most purposes, but there are some
> use cases where having a second UART would be useful (like
> bare-metal testing where you don't really want to have
On 12 December 2017 at 14:45, Andrew Jones wrote:
> Should this be
>
> if (!vmc->no_second_uart && serial_hds[uart_count] != NULL) {
>
> A bit late now, but maybe the other UART resource allocations should have
> been conditional on actually being wired up too?
What does x86 do?
I think the
Marc-André Lureau writes:
> Signed-off-by: Marc-André Lureau
> ---
> scripts/qapi.py | 9 -
> tests/qapi-schema/qapi-schema-test.json | 6 +-
> tests/qapi-schema/qapi-schema-test.out | 8 +++-
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff
On Tue, Dec 12, 2017 at 02:31:05PM +, Ard Biesheuvel wrote:
> On 12 December 2017 at 14:17, Peter Maydell wrote:
> > On 12 December 2017 at 14:16, Ard Biesheuvel
> > wrote:
> >> On 12 December 2017 at 14:13, Peter Maydell
> >> wrote:
> >>> On 12 December 2017 at 14:12, Ard Biesheuvel
> >
On Tue, Dec 12, 2017 at 12:06:39PM +0100, Laszlo Ersek wrote:
> On 12/12/17 06:53, Shannon Zhao wrote:
> >
> >
> > On 2017/12/8 23:02, Peter Maydell wrote:
> >> Add the second UART to the ACPI tables.
> >>
> >> Signed-off-by: Peter Maydell
> >> ---
> >> Pure guesswork, as I don't have a UEFI set
Use the function argument "name" instead of hardcoded
"VMCOREINFO". All callers use "VMCOREINFO" as argument, so this isn't
an exposed bug, thankfully.
Simplify a little bit the code while touching this.
Suggested-by: Andrew Jones
Reported-by: Laszlo Ersek
Signed-off-by: Marc-André Lureau
---
On Tue, Dec 12, 2017 at 01:56:00PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Mostly just manual conversion with very minor fixes.
>
> Signed-off-by: Dr. David Alan Gilbert
Reviewed-by: Peter Xu
Some nits below, but r-b is fine with/without changing them.
Matthew, Wei,
On Tue, Dec 12, 2017 at 12:55 PM, Wei Wang wrote:
> From: Matthew Wilcox
>
> The eXtensible Bitmap is a sparse bitmap representation which is
> efficient for set bits which tend to cluster. It supports up to
> 'unsigned long' worth of bits, and this commit adds the bare bones --
>
On 12/12/17 16:09, Marc-André Lureau wrote:
> Use the function argument "name" instead of hardcoded
> "VMCOREINFO". All callers use "VMCOREINFO" as argument, so this isn't
> an exposed bug, thankfully.
>
> Simplify a little bit the code while touching this.
>
> Suggested-by: Andrew Jones
> Repor
On Tue, Dec 12, 2017 at 02:50:50PM +, Peter Maydell wrote:
> On 12 December 2017 at 14:45, Andrew Jones wrote:
> > Should this be
> >
> > if (!vmc->no_second_uart && serial_hds[uart_count] != NULL) {
> >
> > A bit late now, but maybe the other UART resource allocations should have
> > been
On Fri, Dec 08, 2017 at 03:02:07PM +, Peter Maydell wrote:
> Currently we only provide one non-secure UART on the virt
> board. This is OK for most purposes, but there are some
> use cases where having a second UART would be useful (like
> bare-metal testing where you don't really want to have
On 12.12.2017 15:29, Cornelia Huck wrote:
> On Tue, 12 Dec 2017 15:13:46 +0100
> Christian Borntraeger wrote:
>
>> On 12/12/2017 02:49 PM, Cornelia Huck wrote:
>
>>> One thing I noticed: You removed the caching of the flic (in the old
>>> kvm inject routine), and you generally do more qom invoca
This patch should be moved behind the patch with payload comparition.
People needs look your changes to understand why we need this patch.
Thanks
Zhang Chen
On Wed, Dec 6, 2017 at 9:57 AM, Mao Zhongyi
wrote:
> The th_off field specifies the size of the TCP header, if th_off > 5,
> it only mean
On Wed, Dec 6, 2017 at 5:57 PM, Mao Zhongyi
wrote:
> Modified the function colo_packet_compare_common to prepare for the
> tcp packet comparison in the next patch.
>
> Cc: Zhang Chen
> Cc: Li Zhijian
> Cc: Jason Wang
>
> Signed-off-by: Mao Zhongyi
> ---
> net/colo-compare.c | 71
On Tue, Dec 12, 2017 at 04:09:09PM +0100, Marc-André Lureau wrote:
> Use the function argument "name" instead of hardcoded
> "VMCOREINFO". All callers use "VMCOREINFO" as argument, so this isn't
> an exposed bug, thankfully.
>
> Simplify a little bit the code while touching this.
>
> Suggested-by
1 - 100 of 189 matches
Mail list logo
