Daniel Henrique Barboza writes:
> On 12/4/18 5:15 PM, Eduardo Habkost wrote:
>> On Tue, Dec 04, 2018 at 04:36:56PM -0200, Daniel Henrique Barboza wrote:
>>>
>>> On 11/29/18 4:55 PM, Markus Armbruster wrote:
One more thing...
Markus Armbruster writes:
> Daniel Henrique Bar
Eduardo Habkost writes:
> On Mon, Dec 03, 2018 at 07:07:10PM -0200, Wainer dos Santos Moschetta wrote:
>>
>> On 11/26/2018 08:56 PM, Eduardo Habkost wrote:
>> > Remove the "apic initialization failed" prefix (it conveys no
>> > useful information), replace "invalid" with "too large", and add
>>
Hi,
> NB: the code to asynchronously run code blocks on the
> main thread uses dispatch_get_main_queue(), which is a
> 10.10-or-later function. If we're going to go with this
> refactoring I think the benefit in clarity-of-code is a
> worthwhile gain for dropping support for ancient OSX versions
Public bug reported:
Version:
$ qemu-system-arm --version
QEMU emulator version 3.0.92 (v3.1.0-rc2-31-gd522fba244)
Arm SIE-200 Technical Reference Manual describes that BLK_MAX indicates
the maximum value of "block based index register" (BLK_IDX). For
example, the value 1 would indicate that BLK
On 12/3/18 9:05 AM, Zheng Xiang wrote:
When VM boots from the latest version of linux kernel, after
hot-unpluging virtio-blk disks which are hotplugged into
pcie-root-port, the VM's dmesg log shows:
[ 151.046242] pciehp :00:05.0:pcie004: pending interrupts 0x0001 from Slot
Status
[ 151
On 11/29/18 11:48 PM, Yuval Shaia wrote:
Interface with the device is changed with the addition of support for
MAD packets.
Adjust documentation accordingly.
While there fix a minor mistake which may lead to think that there is a
relation between using RXE on host and the compatibility with b
On 11/29/18 11:47 PM, Yuval Shaia wrote:
The control over the RDMA device's GID table is done by updating the
device's Ethernet function addresses.
Usually the first GID entry is determined by the MAC address, the second
by the first IPv6 address and the third by the IPv4 address. Other
entrie
On 2018-12-04 17:55, Gonzo FWS wrote:
> Right now IncludeOS on x86_64 must use a chainloader for multiboot support.
> The chainloader is an ELF32 kernel that loads the real ELF64 kernel and jumps
> to it. As long as the ELF has the .multiboot section and conforms to the
> spec, meaning _start is
The virtio-balloon always works in units of 4kiB (BALLOON_PAGE_SIZE), but
we can only actually discard memory in units of the host page size.
Now, we handle this very badly: we silently ignore balloon requests that
aren't host page aligned, and for requests that are host page aligned we
discard th
This replaces the balloon_page() internal interface with
ballon_inflate_page(), with a slightly different interface. The new
interface will make future alterations simpler.
Signed-off-by: David Gibson
Reviewed-by: David Hildenbrand
Reviewed-by: Michael S. Tsirkin
---
hw/virtio/virtio-balloon.
Currently, virtio-balloon uses madvise() with MADV_DONTNEED to actually
discard RAM pages inserted into the balloon. This is basically a Linux
only interface (MADV_DONTNEED exists on some other platforms, but doesn't
always have the same semantics). It also doesn't work on hugepages and has
some
The virtio-balloon device's verification of the address given to it by the
guest has a number of faults:
* The addresses here are guest physical addresses, which should be
'hwaddr' rather than 'ram_addr_t' (the distinction is admittedly
pretty subtle and confusing)
* We don't ch
When the balloon is inflated, we discard memory place in it using madvise()
with MADV_DONTNEED. And when we deflate it we use MADV_WILLNEED, which
sounds like it makes sense but is actually unnecessary.
The misleadingly named MADV_DONTNEED just discards the memory in question,
it doesn't set any
The virtio-balloon devices was never really thought out for cases
other than 4kiB pagesize on both guest and host. It works in some
cases, but in others can be ineffectual or even cause guest memory
corruption.
This series makes a handful of preliminary cleanups, then makes a
change to safely, th
On Tue, Dec 04, 2018 at 10:30:18AM +0100, Roger Pau Monné wrote:
> On Tue, Dec 04, 2018 at 02:50:49AM -0500, Zhao Yan wrote:
> > For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
> > doesn't support INTx mode, so its machine irq read from host sysfs is 0.
> > In that case, repor
Patchew URL:
https://patchew.org/QEMU/1543961939-2419-1-git-send-email-wall...@linux.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v1] s390: guest support for diagnose 318 and limit
max VCPU
On 2018/12/5 上午9:59, Michael S. Tsirkin wrote:
On Wed, Dec 05, 2018 at 09:30:19AM +0800, Jason Wang wrote:
On 2018/12/5 上午2:37, Jintack Lim wrote:
Hi,
I'm wondering how the current implementation works when logging dirty
pages during migration from vhost-net (in kernel) when used vIOMMU.
I
On Tue, Dec 04, 2018 at 06:04:13PM +0100, Cédric Le Goater wrote:
> On 12/4/18 2:54 AM, David Gibson wrote:
> > On Mon, Dec 03, 2018 at 06:05:12PM +0100, Cédric Le Goater wrote:
> >> I forgot to reply to this one.
> >>
> >> On 11/29/18 1:47 AM, David Gibson wrote:
> >>> On Wed, Nov 28, 2018 at 11:5
On Tue, Dec 04, 2018 at 04:14:12PM +0100, Cédric Le Goater wrote:
> On 11/28/18 11:37 PM, Cédric Le Goater wrote:
> > On 11/28/18 5:42 AM, David Gibson wrote:
> >> On Fri, Nov 16, 2018 at 11:57:12AM +0100, Cédric Le Goater wrote:
> >>> The interrupt mode is statically defined to XIVE only for this
On Tue, Dec 04, 2018 at 06:12:11PM +0100, Cédric Le Goater wrote:
> [ ... ]
>
> >>> +void spapr_xive_pic_print_info(sPAPRXive *xive, Monitor *mon)
> >>> +{
> >>> +int i;
> >>> +uint32_t offset = 0;
> >>> +
> >>> +monitor_printf(mon, "XIVE Source %08x .. %08x\n", offset,
> >>> +
On Wed, Dec 05, 2018 at 09:30:19AM +0800, Jason Wang wrote:
>
> On 2018/12/5 上午2:37, Jintack Lim wrote:
> > Hi,
> >
> > I'm wondering how the current implementation works when logging dirty
> > pages during migration from vhost-net (in kernel) when used vIOMMU.
> >
> > I understand how vhost-net
On Tue, Dec 04, 2018 at 04:27:48PM -0200, Eduardo Habkost wrote:
> On Mon, Dec 03, 2018 at 09:28:36AM -0700, Alex Williamson wrote:
> > Including all machine types that might have a pcie-root-port.
> >
> > Cc: Peter Maydell
> > Cc: Michael S. Tsirkin
> > Cc: Marcel Apfelbaum
> > Cc: Paolo Bonzi
On 2018/12/5 上午2:37, Jintack Lim wrote:
Hi,
I'm wondering how the current implementation works when logging dirty
pages during migration from vhost-net (in kernel) when used vIOMMU.
I understand how vhost-net logs GPAs when not using vIOMMU. But when
we use vhost with vIOMMU, then shouldn't v
>On Tue, 4 Dec 2018 at 00:41, wrote:
>>
>> >I would still prefer to see a more detailed examination of whether
>> >we can do this with a PCI device before we commit to taking the
>> >MMIO version into the virt board.
>>
>> I'm sorry I thought I had sent an email. yesterday when I wrote an email to
Patchew URL:
https://patchew.org/QEMU/20181204184657.78028-1-vsement...@virtuozzo.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEG
On 12/3/2018 8:35 AM, Stefano Garzarella wrote:
On Mon, Dec 3, 2018 at 4:44 PM Rob Bradford wrote:
Hi Stefano, thanks for capturing all these numbers,
On Mon, 2018-12-03 at 15:27 +0100, Stefano Garzarella wrote:
Hi Rob,
I continued to investigate the boot time, and as you suggested I
looked a
I screen-scraped the @ibm address again (Conny was the victim this time)
Reply to this thread to avoid any delivery failures.
On 12/4/18 5:18 PM, Collin Walling wrote:
> Add migration and reset support for diagnose 318. This is a new z14 GA2
> hardware feature, but we can provide guest support s
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
fifth release candidate for the QEMU 3.1 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu-project.org/qemu-3.1.0-rc4.tar.xz
http://downl
Add migration and reset support for diagnose 318. This is a new z14 GA2
hardware feature, but we can provide guest support starting with the
zEC12-full CPU model.
Because new hardware introduces a new facility-availability byte in
the Read SCP Info block, we lose one byte in the CPU entries lis
On Tue, 4 Dec 2018 19:29:25 +
Peter Maydell wrote:
> On Tue, 4 Dec 2018 at 19:26, Alex Williamson
> wrote:
> >
> > On Tue, 4 Dec 2018 20:16:44 +0100
> > Christian Borntraeger wrote:
> >
> > > I think Conny has already added the s390/ccw part to her next tree.
> > > From a quick glimpse b
On 12/4/18 5:15 PM, Eduardo Habkost wrote:
On Tue, Dec 04, 2018 at 04:36:56PM -0200, Daniel Henrique Barboza wrote:
On 11/29/18 4:55 PM, Markus Armbruster wrote:
One more thing...
Markus Armbruster writes:
Daniel Henrique Barboza writes:
The qmp/hmp command 'system_wakeup' is simply
On 04.12.2018 20:56, Alex Williamson wrote:
> On Tue, 4 Dec 2018 19:29:25 +
> Peter Maydell wrote:
>
>> On Tue, 4 Dec 2018 at 19:26, Alex Williamson
>> wrote:
>>>
>>> On Tue, 4 Dec 2018 20:16:44 +0100
>>> Christian Borntraeger wrote:
>>>
I think Conny has already added the s390/c
On Tue, Dec 04, 2018 at 18:34:18 +, Alex Bennée wrote:
>
> Emilio G. Cota writes:
(snip)
> > Note that the IBM and ARM machines benefit from having
> > HARDFLOAT_2F{32,64}_USE_FP set to 0. Otherwise their performance
> > can suffer significantly:
>
> Is this just the latency of pushing the n
On Tue, Dec 04, 2018 at 07:16:39PM +, Peter Maydell wrote:
> On Tue, 4 Dec 2018 at 19:05, Eduardo Habkost wrote:
> > On Tue, Dec 04, 2018 at 06:24:19PM +, Peter Maydell wrote:
> > > A cluster is a group of CPUs which are all identical and have
> > > the same view of the rest of the system.
Hi
On Tue, Dec 4, 2018 at 11:17 PM Christian Borntraeger
wrote:
>
> I think Conny has already added the s390/ccw part to her next tree.
> From a quick glimpse both patches look identical.
>
I also have them in my machine compatibilities series:
https://patchew.org/QEMU/20181204142023.15982-1-marc
On Tue, 4 Dec 2018 at 19:26, Alex Williamson wrote:
>
> On Tue, 4 Dec 2018 20:16:44 +0100
> Christian Borntraeger wrote:
>
> > I think Conny has already added the s390/ccw part to her next tree.
> > From a quick glimpse both patches look identical.
>
> If so then we can just use the original v3 v
On Tue, 4 Dec 2018 20:16:44 +0100
Christian Borntraeger wrote:
> I think Conny has already added the s390/ccw part to her next tree.
> From a quick glimpse both patches look identical.
If so then we can just use the original v3 version of this patch that
touches all but ccw and let them come to
I think Conny has already added the s390/ccw part to her next tree.
>From a quick glimpse both patches look identical.
On 04.12.2018 20:04, Alex Williamson wrote:
> For upcoming pcie-root-port compatibility, among possibly others.
>
> Cc: Peter Maydell
> Cc: Michael S. Tsirkin
> Cc: Marcel Apf
On Tue, 4 Dec 2018 at 19:05, Eduardo Habkost wrote:
> On Tue, Dec 04, 2018 at 06:24:19PM +, Peter Maydell wrote:
> > A cluster is a group of CPUs which are all identical and have
> > the same view of the rest of the system.
> With that definition in mind, why can't QEMU cluster CPUs
> automat
On Tue, Dec 04, 2018 at 04:36:56PM -0200, Daniel Henrique Barboza wrote:
>
>
> On 11/29/18 4:55 PM, Markus Armbruster wrote:
> > One more thing...
> >
> > Markus Armbruster writes:
> >
> > > Daniel Henrique Barboza writes:
> > >
> > > > The qmp/hmp command 'system_wakeup' is simply a direct
On Tue, Dec 04, 2018 at 02:53:26PM +0100, Paolo Bonzini wrote:
> On 04/12/18 14:43, Peter Maydell wrote:
> > The point about PCI is that it is the same everywhere and
> > discoverable, and easy for the user to add to the system or not.
> > MMIO requires extra work for every board model that we want
Emilio G. Cota writes:
> On Tue, Dec 04, 2018 at 13:52:16 +, Alex Bennée wrote:
>> > We could always
>> >
>> > #ifdef __FAST_MATH__
>> > #error "Silliness like this will get you nowhere"
>> > #endif
>>
>> Emilio, are you happy to add that guard with a suitable pithy comment?
>
> Isn't it be
On Tue, Dec 04, 2018 at 06:24:19PM +, Peter Maydell wrote:
> On Tue, 4 Dec 2018 at 18:06, Eduardo Habkost wrote:
> > In either case, I'm still missing a clear description of what a
> > cluster is supposed to represent, exactly (see my previous reply
> > on this thread).
>
> Here's my attempt:
For upcoming pcie-root-port compatibility, among possibly others.
Cc: Peter Maydell
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: David Hildenbrand
Cc: Cornelia Huck
Cc: Christian Borntraeger
Acked-by: David Gibson
Signed-off-
On Tue, 4 Dec 2018 at 18:50, Vladimir Sementsov-Ogievskiy
wrote:
>
> Free block->cipher and block->ivgen on error path.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> crypto/block-luks.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/crypto/block-luks.c b/crypto/block-luks.
Introduce QCryptoBlock-based functions and use them where possible.
This is needed to implement thread-safe encrypt/decrypt operations.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
crypto/blockpriv.h | 14 ++
crypto/block-luks.c | 14 ++
crypto/block-qcow.c | 14 +
Rename qcrypto_block_*crypt_helper to qcrypto_cipher_*crypt_helper, as
it's not about QCryptoBlock. This is needed to introduce
qcrypto_block_*crypt_helper in the next commit, which will have
QCryptoBlock pointer and than will be able to use additional fields of
it, which in turn will be used to im
Hi all.
These series are preliminary step before moving encryption code in
qcow2 to the threads. The first attempt of doing it is on list
([PATCH 00/11] qcow2: encryption threads :
https://lists.gnu.org/archive/html/qemu-block/2018-11/msg00729.html)
But it's approach with multiplying the whole Q
qcrypto_block_encrypt_helper and qcrypto_block_decrypt_helper are
almost identical, let's reduce code duplication and simplify further
improvements.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
crypto/block.c | 81 +++---
1 file changed, 31 insertio
Free block->cipher and block->ivgen on error path.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
crypto/block-luks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 5738124773..51e24d23ca 100644
--- a/crypto/block-luks.c
+++ b/crypto/block
The two thing that should be handled are cipher and ivgen. For ivgen
the solution is just mutex, as iv calculations should not be long in
comparison with encryption/decryption. And for cipher let's just keep
per-thread ciphers.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
crypto/blockpriv.h
On Tue, Dec 04, 2018 at 02:17:24PM +0100, Igor Mammedov wrote:
> On Fri, 30 Nov 2018 09:41:42 -0200
> Eduardo Habkost wrote:
>
> > On Fri, Nov 30, 2018 at 11:55:26AM +0100, Igor Mammedov wrote:
> > > On Fri, 30 Nov 2018 01:36:03 +0400
> > > Marc-André Lureau wrote:
> > >
> > > > Hi
> > > >
>
On Tue, Dec 04, 2018 at 06:25:35PM +0100, Markus Armbruster wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
>
> This commit was created with scripts/clean-includes, with the changes
> to the following files manually reverted:
>
Emilio G. Cota writes:
> Performance results (single and double precision) for fp-bench:
>
> 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
> - before:
> add-single: 135.07 MFlops
> add-double: 131.60 MFlops
> sub-single: 130.04 MFlops
> sub-double: 133.01 MFlops
> - after:
> add-single: 443.04 MF
Hi,
I'm wondering how the current implementation works when logging dirty
pages during migration from vhost-net (in kernel) when used vIOMMU.
I understand how vhost-net logs GPAs when not using vIOMMU. But when
we use vhost with vIOMMU, then shouldn't vhost-net need to log the
translated address
On Tue, 4 Dec 2018 at 18:06, Eduardo Habkost wrote:
> In either case, I'm still missing a clear description of what a
> cluster is supposed to represent, exactly (see my previous reply
> on this thread).
Here's my attempt:
A cluster is a group of CPUs which are all identical and have
the same vi
On Mon, 3 Dec 2018 at 16:28, Alex Williamson wrote:
>
> Including all machine types that might have a pcie-root-port.
We should bump the version for every versioned machine
we have, whether it has a pcie-root-port or not.
Otherwise we'll forget at the end of the release
cycle again...
thanks
--
On 11/29/18 4:55 PM, Markus Armbruster wrote:
One more thing...
Markus Armbruster writes:
Daniel Henrique Barboza writes:
The qmp/hmp command 'system_wakeup' is simply a direct call to
'qemu_system_wakeup_request' from vl.c. This function verifies if
runstate is SUSPENDED and if the wak
On Mon, Dec 03, 2018 at 09:28:36AM -0700, Alex Williamson wrote:
> Including all machine types that might have a pcie-root-port.
>
> Cc: Peter Maydell
> Cc: Michael S. Tsirkin
> Cc: Marcel Apfelbaum
> Cc: Paolo Bonzini
> Cc: Richard Henderson
> Cc: Eduardo Habkost
> Cc: David Gibson
> Signe
On Mon, Dec 03, 2018 at 07:07:10PM -0200, Wainer dos Santos Moschetta wrote:
>
> On 11/26/2018 08:56 PM, Eduardo Habkost wrote:
> > Remove the "apic initialization failed" prefix (it conveys no
> > useful information), replace "invalid" with "too large", and add
> > an error hint with two possible
On Mon, Dec 03, 2018 at 03:17:06PM +0100, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
[...]
> > But note that we might still be able to move the existing
> > "hyperv_*" features to feature_word_info[].feat_names. We just
> > need to keep the same semantics (e.g. enable
> > HV_HYPERCALL_AVAI
On Mon, Dec 03, 2018 at 03:09:14PM +0100, Luc Michel wrote:
>
>
> On 12/3/18 12:23 PM, Peter Maydell wrote:
> > On Mon, 3 Dec 2018 at 11:21, Luc Michel wrote:
> >>
> >> On 11/30/18 5:52 PM, Peter Maydell wrote:
> >>> Luc: what are the requirements on boards using CPU cluster
> >>> objects? I ass
On 12/4/18 11:25 AM, Markus Armbruster wrote:
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes, with the changes
to the following files manually reverted:
contrib/libvhost-user/li
On Tue, 4 Dec 2018 at 15:43, Peter Maydell wrote:
>
> On Tue, 4 Dec 2018 at 15:34, Stefan Berger wrote:
> >
> > This series of patches removes an unnecessary parameter from tpm_tis_abort()
> > and adds a locality range check (using assert()) to tpm_tis_prep_abort() and
> > tpm_tis_request_complet
Hi Li,
On 3/12/18 15:48, Li Zhijian wrote:
> Some address/memory APIs have different type between
> 'hwaddr/target_ulong addr' and 'int len'. It is very unsafety, espcially
I'm not native English speaker, but I think this should be spell:
... "very unsafe, especially" ...
> some APIs will be pa
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul Durrant
> Sent: 04 December 2018 15:20
> To: Anthony Perard
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-devel@nongnu.org;
> Max Reitz ; xen-
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes, with the changes
to the following files manually reverted:
contrib/libvhost-user/libvhost-user-glib.h
contrib/libvhost-user/libv
On Tue, Dec 04, 2018 at 13:52:16 +, Alex Bennée wrote:
> > We could always
> >
> > #ifdef __FAST_MATH__
> > #error "Silliness like this will get you nowhere"
> > #endif
>
> Emilio, are you happy to add that guard with a suitable pithy comment?
Isn't it better to just disable hardfloat then?
On 04/12/18 16:49, Christophe de Dinechin wrote:
>> Linux and QEMU's own qht work just fine with compile-time directives.
>
> Wouldn’t it work fine without any compile-time directive at all?
Yes, that's what I meant. Though there are certainly cases in which the
difference without proper cachel
[ ... ]
>>> +void spapr_xive_pic_print_info(sPAPRXive *xive, Monitor *mon)
>>> +{
>>> +int i;
>>> +uint32_t offset = 0;
>>> +
>>> +monitor_printf(mon, "XIVE Source %08x .. %08x\n", offset,
>>> + offset + xive->source.nr_irqs - 1);
>>> +xive_source_pic_print_info(&
On Tue, 4 Dec 2018 11:53:33 +0100
Cornelia Huck wrote:
> On Tue, 27 Nov 2018 12:52:48 -0700
> Alex Williamson wrote:
>
> > Actually I'm wondering if we can distill everything down to two bits,
> > STOPPED and LOGGING.
> >
> > We start at RUNNING, the user can optionally enable LOGGING when
> >
Right now IncludeOS on x86_64 must use a chainloader for multiboot support. The
chainloader is an ELF32 kernel that loads the real ELF64 kernel and jumps to
it. As long as the ELF has the .multiboot section and conforms to the spec,
meaning _start is be a 32-bit entry, it should be fine.
By rem
On 4/12/18 17:26, Alex Williamson wrote:
> In preparation for reporting higher virtual link speeds and widths,
> create enums and macros to help us manage them.
>
> Cc: Michael S. Tsirkin
> Cc: Marcel Apfelbaum
> Tested-by: Geoffrey McRae
> Signed-off-by: Alex Williamson
Reviewed-by: Philippe
On 12/4/18 2:54 AM, David Gibson wrote:
> On Mon, Dec 03, 2018 at 06:05:12PM +0100, Cédric Le Goater wrote:
>> I forgot to reply to this one.
>>
>> On 11/29/18 1:47 AM, David Gibson wrote:
>>> On Wed, Nov 28, 2018 at 11:59:58AM +0100, Cédric Le Goater wrote:
On 11/28/18 12:49 AM, David Gibson
On 4/12/18 14:29, Peter Maydell wrote:
> The test-arm-mptimer setup creates a lot of test names using
> g_strdup_printf() and never frees them. This is entirely
> harmless since it's one-shot test code, but it clutters
> up the output from clang's LeakSanitizer. Refactor to
> use a helper function
On Wed, Nov 21, 2018 at 03:12:10PM +, Paul Durrant wrote:
> I have made many significant contributions to the Xen code in QEMU,
> particularly the recent patches introducing a new PV device framework.
> I intend to make further significant contributions, porting other PV back-
> ends to the new
On Wed, Nov 21, 2018 at 03:12:09PM +, Paul Durrant wrote:
> This patch adds a creator function for XenQdiskDevice-s so that they can
> be created automatically when the Xen toolstack instantiates a new
> PV backend. When the XenQdiskDevice is created this way it is also
> necessary to create a
Create properties to be able to define speeds and widths for PCIe
links. The only tricky bit here is that our get and set callbacks
translate from the fixed QAPI automagic enums to those we define
in PCI code to represent the actual register segment value.
Cc: Eric Blake
Cc: Markus Armbruster
T
On Tue, 4 Dec 2018 16:10:52 +0100
Andrew Jones wrote:
> On Fri, Nov 30, 2018 at 02:00:32PM +0100, Samuel Ortiz wrote:
> > The only remaining AcpiRsdpDescriptor users are the ACPI utils for the
> > BIOS table tests.
> > We remove that dependency and can thus remove the structure itself.
> >
> > S
Make use of the PCIESlot speed and width fields to update link
information beyond those configured in pcie_cap_v1_fill(). This is
only called for devices supporting a version 2 capability and
automatically skips any non-PCIESlot devices. Only devices with
increased link values generate any visibl
Now that the downstream port will virtually negotiate itself to the
link status of the downstream devie, we can remove this emulation.
It's not clear that it was every terribly useful anyway.
Tested-by: Geoffrey McRae
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c |6 --
1 file change
Allow users to experimentally specify speed and width values for the
generic PCIe root port. Defaults remain at 2.5GT/s & x1 for
compatiblity with the intent to only support changing defaults via
machine types for now.
Note for libvirt testing that pcie-root-port controllers are given
default nam
On 12/4/18 9:32 AM, Marc-André Lureau wrote:
+++ b/scripts/qapi/types.py
@@ -201,6 +201,7 @@ class QAPISchemaGenTypeVisitor(QAPISchemaModularCVisitor):
''',
types=types, visit=visit))
self._genh.preamble_add(mcgen('''
+#include "qemu/osdep.h"
Change the default speed and width for new machine types to the
fastest and widest currently supported. This should be compatible to
the PCIe 4.0 spec. Pre-QEMU-4.0 machine types remain at 2.5GT/s, x1
width.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Alex Williamson
---
hw/pc
Including all machine types that might have a pcie-root-port.
Cc: Peter Maydell
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Acked-by: David Gibson
Signed-off-by: Alex Williamson
---
hw/arm/virt.c| 19 +--
In preparation for reporting higher virtual link speeds and widths,
create enums and macros to help us manage them.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Tested-by: Geoffrey McRae
Signed-off-by: Alex Williamson
---
hw/pci/pcie.c |7 ---
hw/vfio/pci.c |
The PCIe link speed and width between a downstream device and its
upstream port is negotiated on real hardware and susceptible to
dynamic changes due to signal issues and power management. In the
emulated device case there is no real hardware link, but we still
might wish to have some consistency
Add fields allowing the PCIe link speed and width of a PCIESlot to
be configured, with an instance_post_init callback on the root port
parent class to set defaults. This allows child classes to set these
via properties or via their own instance_init callback, without
requiring all implementions to
v2->v3:
- Michael suggested offline that we not commit the pcie-root-port
driver API to support arbitrary speeds and widths without some
necessary use case where it's required to set these outside of
the machine type defaults. These options therefore become
experimental, x-speed and x
Marc-André Lureau writes:
> Hi
>
> On Tue, Dec 4, 2018 at 7:23 PM Markus Armbruster wrote:
>>
>> Marc-André Lureau writes:
>>
>> > Now that the schema can be configured, it is crucial that all types
>> > are configured the same. Make sure config-host.h is included, so
>> > build-sys tracks the
On 2018-12-03 16:32, Paolo Bonzini wrote:
> There is no reason for CONFIG_VHOST_NET to be specific to a single target;
> it is a host feature that can be add to all targets, as long as they support
> the virtio-net device. Currently CONFIG_VHOST_NET depends on CONFIG_KVM,
> but ioeventfd support i
On Tue, 4 Dec 2018 16:01:24 +0100
Halil Pasic wrote:
> On Tue, 4 Dec 2018 14:38:02 +0100
> Christian Borntraeger wrote:
>
> > Halil does more work in this area than I do right now. Lets add Halil.
> >
> > Signed-off-by: Christian Borntraeger
>
> Acked-by: Halil Pasic
Thanks, applied.
>
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 15:49
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-devel@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH 03
On Tue, Dec 04, 2018 at 03:20:04PM +, Paul Durrant wrote:
> > > +static char *disk_to_vbd_name(unsigned int disk)
> > > +{
> > > +unsigned int len = DIV_ROUND_UP(disk, 26);
> > > +char *name = g_malloc0(len + 1);
> > > +
> > > +do {
> > > +name[len--] = 'a' + (disk % 26);
>
> On 27 Nov 2018, at 14:51, Paolo Bonzini wrote:
>
> On 27/11/18 13:49, Christophe de Dinechin wrote:
>> So this is not really
>> helping. Also, the ThreadLocal structure itself is not necessarily aligned
>> within struct Threads. Therefore, it’s possible that “requests” for example
>> could b
On Tue, 4 Dec 2018 at 15:34, Stefan Berger wrote:
>
> This series of patches removes an unnecessary parameter from tpm_tis_abort()
> and adds a locality range check (using assert()) to tpm_tis_prep_abort() and
> tpm_tis_request_completed().
>
>Stefan
>
> The following changes since commit 83ea
On 11/29/18 10:18 AM, Markus Armbruster wrote:
Daniel Henrique Barboza writes:
This patch updates the descriptions of 'guest-suspend-ram' and
'guest-suspend-hybrid' to mention that both commands relies now
on the proper support for wake up from suspend, retrieved by the
'wakeup-suspend-supp
On Wed, Nov 21, 2018 at 03:12:08PM +, Paul Durrant wrote:
> +xen_backend_device_create(BUS(xenbus), type, name, opts, &local_err);
> +qobject_unref(opts);
> +
> +if (local_err) {
> +const char *msg = error_get_pretty(local_err);
> +
> +error_report("failed to create
This series of patches removes an unnecessary parameter from tpm_tis_abort()
and adds a locality range check (using assert()) to tpm_tis_prep_abort() and
tpm_tis_request_completed().
Stefan
The following changes since commit 83ea23cd207a03c5736be0231acbf7f8b05dbf52:
i386: hvf: Fix overrun o
Make sure that the new locality passed to tpm_tis_prep_abort()
is valid.
Add a comment to aborting_locty that it may be any locality, including
TPM_TIS_NO_LOCALITY.
Signed-off-by: Stefan Berger
Reviewed-by: Marc-André Lureau
---
hw/tpm/tpm_tis.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
1 - 100 of 216 matches
Mail list logo
