Hi Drew,
On 9/24/19 1:31 PM, Andrew Jones wrote:
> Enable SVE in the KVM guest when the 'max' cpu type is configured
> and KVM supports it. KVM SVE requires use of the new finalize
> vcpu ioctl, so we add that now too. For starters SVE can only be
> turned on or off, getting all vector lengths the
Hi Drew,
On 9/24/19 1:31 PM, Andrew Jones wrote:
> Extend the SVE vq map initialization and validation with KVM's
> supported vector lengths when KVM is enabled. In order to determine
> and select supported lengths we add two new KVM functions for getting
> and setting the KVM_REG_ARM64_SVE_VLS ps
Philippe Mathieu-Daudé writes:
> On 9/24/19 2:44 PM, Sergio Lopez wrote:
>> Microvm is a machine type inspired by both NEMU and Firecracker, and
>> constructed after the machine model implemented by the latter.
>>
>> It's main purpose is providing users a minimalist machine type free
>> from th
Paolo Bonzini writes:
> On 25/09/19 17:04, Sergio Lopez wrote:
>> I'm going back to this level of the thread, because after your
>> suggestion I took a deeper look at how things work around the PIC, and
>> discovered I was completely wrong about my assumptions.
>>
>> For virtio-mmio devices, gi
Hi,
hw/watchdog/wdt_diag288.c use 2 different resets:
1/ registered handler:
qemu_register_reset(diag288_reset, diag288);
2/ DeviceClass reset:
dc->reset = wdt_diag288_reset;
diag288_reset() simply calls wdt_diag288_reset():
static void wdt_diag288_reset(DeviceState *dev)
{
DIAG2
Patchew URL: https://patchew.org/QEMU/20190925174400.8578-1-stefa...@redhat.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
On 9/26/19 7:58 AM, Thomas Huth wrote:
> On 25/09/2019 22.51, Philippe Mathieu-Daudé wrote:
> [...]
>> Let's say I have write access to a LAN TFTP server used by some PXE
>> bootloader where I can store my crafted nasty kernel, then I get this score:
>>
>> https://nvd.nist.gov/vuln-metrics/cvss/v3-
On 25/09/2019 22.51, Philippe Mathieu-Daudé wrote:
[...]
> Let's say I have write access to a LAN TFTP server used by some PXE
> bootloader where I can store my crafted nasty kernel, then I get this score:
>
> https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:A/AC:L/PR:N/UI:N/S:C/C:H/
That's looking much better :) And finally, how many failures do you get
running the same test under QEMU 3.1? If that gives you zero failures
then I'll need to look a lot closer at the changes to try and figure out
what is going on.
As a matter of interest, which tests are the ones that are faili
On 25/09/2019 22.51, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
>
> On 9/25/19 3:03 PM, Thomas Huth wrote:
>> Both, "rom->addr" and "addr" are derived from the binary image
>> that can be loaded with the "-kernel" paramer. The code in
>> rom_copy() then calculates:
>>
>> d = dest + (rom->addr
On 9/26/19 4:10 AM, Tao Xu wrote:
> Drop the duplicated definition of cpuid AVX512_VBMI macro and rename
> it as CPUID_7_0_ECX_AVX512_VBMI. Rename CPUID_7_0_ECX_VBMI2 as
> CPUID_7_0_ECX_AVX512_VBMI2.
>
> Acked-by: Stefano Garzarella
> Signed-off-by: Tao Xu
> ---
> target/i386/cpu.c |
Hi Alex,
On 9/26/19 1:34 AM, Alex Bennée wrote:
> Philippe Mathieu-Daudé writes:
>> On 9/24/19 11:01 PM, Alex Bennée wrote:
>>> From: John Snow
>>>
>>> There isn't a debian.dockerfile anymore,
>>> so perform some ghost-busting.
>>
>> Won't we deprecate other images in the future?
>
> Sure but w
On 9/26/19 1:31 AM, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/4b9204cc8ade1c965dc5412c53c6f7c5b4f019a2.1569413332.git.tgole...@redhat.com/
>
> Hi,
>
> This series failed the asan build test. Please find the testing commands and
> their output below. If you have Docker
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, September 26, 2019 3:06 AM
[...]
> > > > The second point is about write-protection:
> > > >
> > > > > There is another value of recording GPA in VFIO. Vendor drivers
> > > > > (e.g. GVT-g) may need to selectively write-p
On Wed, Sep 25, 2019 at 09:59:52AM +0200, Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:18 +1000
> David Gibson wrote:
>
> > Currently TYPE_XICS_BASE and TYPE_XICS_SIMPLE have their own reset methods,
> > using the standard technique for having the subtype call the supertype's
> > methods before d
On Wed, Sep 25, 2019 at 10:17:46PM +0200, Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:25 +1000
> David Gibson wrote:
>
> > spapr global irq numbers are different from the source numbers on the ICS
> > when using XICS - they're offset by XICS_IRQ_BASE (0x1000). But
> > spapr_irq_set_irq_xics() w
On Tue, Sep 24, 2019 at 01:00:00PM +0200, Cédric Le Goater wrote:
> On 24/09/2019 12:04, Philippe Mathieu-Daudé wrote:
> > Hi Cédric,
> >
> > On 9/24/19 11:55 AM, Cédric Le Goater wrote:
> >> On 24/09/2019 09:52, Greg Kurz wrote:
> >>> On Tue, 24 Sep 2019 07:22:51 +0200
> >>> Cédric Le Goater wro
On Wed, Sep 25, 2019 at 06:07:40PM +0200, Greg Kurz wrote:
> Recent patch "spapr/irq: Only claim VALID interrupts at the KVM level"
> broke migration of older machine types started with ic-mode=xive:
>
> qemu-system-ppc64: KVM_SET_DEVICE_ATTR failed: Group 3 attr
> 0x1300: Invalid arg
Drop the duplicated definition of cpuid AVX512_VBMI macro and rename
it as CPUID_7_0_ECX_AVX512_VBMI. Rename CPUID_7_0_ECX_VBMI2 as
CPUID_7_0_ECX_AVX512_VBMI2.
Acked-by: Stefano Garzarella
Signed-off-by: Tao Xu
---
target/i386/cpu.c | 8
target/i386/cpu.h | 5 ++---
Add some comments, clean up comments over 80 chars per line. There
is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD, remove
the extra enter and spaces.
Drop the duplicated definition of cpuid AVX512_VBMI macro and rename it
as CPUID_7_0_ECX_AVX512_VBMI. Rename CPUID_7_0_ECX_VBMI2
as CPU
Add some comments, clean up comments over 80 chars per line. And there
is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD, remove
the extra enter and spaces.
Acked-by: Stefano Garzarella
Signed-off-by: Tao Xu
---
target/i386/cpu.h | 164 ++
1
On Wed, Sep 25, 2019 at 10:31:12AM +0200, Greg Kurz wrote:
> On Wed, 25 Sep 2019 10:16:10 +0200
> Greg Kurz wrote:
>
> > On Wed, 25 Sep 2019 16:45:19 +1000
> > David Gibson wrote:
> >
> > > TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
> > > instantiated, and the only one we'
On Wed, Sep 25, 2019 at 09:31:54AM +0200, Cédric Le Goater wrote:
> On 25/09/2019 08:45, David Gibson wrote:
> > This method is used to set up the interrupt backends for the current
> > configuration. However, this means some confusing redirection between
> > the "dual" mode init and the init hook
On Wed, Sep 25, 2019 at 10:55:35AM +0200, Cédric Le Goater wrote:
> On 25/09/2019 10:40, Greg Kurz wrote:
> > On Wed, 25 Sep 2019 16:45:20 +1000
> > David Gibson wrote:
> >
> >> We create a subtype of TYPE_ICS specifically for sPAPR. For now all this
> >> does is move the setup of the PAPR speci
On Wed, Sep 25, 2019 at 09:05:34AM +0200, Cédric Le Goater wrote:
> On 25/09/2019 08:45, David Gibson wrote:
> > Both the XICS and XIVE interrupt backends have a "nr-irqs" property, but
> > it means slightly different things. For XICS (or, strictly, the ICS) it
> > indicates the number of "real" e
On Wed, Sep 25, 2019 at 10:16:10AM +0200, Greg Kurz wrote:
> On Wed, 25 Sep 2019 16:45:19 +1000
> David Gibson wrote:
>
> > TYPE_ICS_SIMPLE is the only subtype of TYPE_ICS_BASE that's ever
> > instantiated, and the only one we're ever likely to want. The
> > existence of different classes is jus
On Wed, Sep 25, 2019 at 09:25:47AM +0200, Cédric Le Goater wrote:
> On 25/09/2019 08:45, David Gibson wrote:
> > spapr_xive_irq_claim() returns a bool to indicate if it succeeded. But
> > most of the callers and one callee use a richer Error * instead. So use
> > that instead of a bool return so
On 9/25/2019 4:42 PM, Stefano Garzarella wrote:
Hi Tao,
Typo in the commit title and message? s/marco/macro?
On Tue, Sep 24, 2019 at 09:02:09AM +0800, Tao Xu wrote:
Drop the duplicated definition of cpuid AVX512_VBMI and marco and
I'm not native speaker but I'd remove some 'and' ^ this
From: Guo Ren
Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
need to ignore them. They cannot be a part of ppn.
1: The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
4.4 Sv39: Page-Based 39-bit Virtual-Memory System
4.5 Sv48: Page-Based 48-bit V
On Wed, Sep 25, 2019 at 01:51:05PM +0200, Igor Mammedov wrote:
> On Wed, 25 Sep 2019 11:27:00 +0800
> Peter Xu wrote:
>
> > On Tue, Sep 24, 2019 at 10:47:51AM -0400, Igor Mammedov wrote:
> > > s390 was trying to solve limited KVM memslot size issue by abusing
> > > memory_region_allocate_system_m
Thx, Sincerely
On Thu, Sep 26, 2019 at 6:52 AM Alistair Francis wrote:
>
> On Wed, Sep 25, 2019 at 5:05 AM wrote:
> >
> > From: Guo Ren
> >
> > Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
> > need to ignore them. They cannot be a part of ppn.
> >
> > 1: The RISC-V I
On Wed, Sep 25, 2019 at 02:09:15PM +0200, Igor Mammedov wrote:
> On Wed, 25 Sep 2019 11:12:11 +0800
> Peter Xu wrote:
>
> > On Tue, Sep 24, 2019 at 10:47:50AM -0400, Igor Mammedov wrote:
> >
> > [...]
> >
> > > @@ -2877,6 +2912,7 @@ static bool kvm_accel_has_memory(MachineState *ms,
> > > Addr
Philippe Mathieu-Daudé writes:
> On 9/24/19 11:01 PM, Alex Bennée wrote:
>> From: John Snow
>>
>> There isn't a debian.dockerfile anymore,
>> so perform some ghost-busting.
>
> Won't we deprecate other images in the future?
Sure but we can just drop them from dockerfiles. It's not like we
all
Patchew URL:
https://patchew.org/QEMU/4b9204cc8ade1c965dc5412c53c6f7c5b4f019a2.1569413332.git.tgole...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST
The 32 bit hosts are already a second class citizen especially with
support for running 64 bit guests under TCG. We are also limited by
testing as actual working 32 bit machines are getting quite rare in
developers personal menageries. For TCG supporting newer types like
Int128 is a lot harder with
On Wed, Sep 25, 2019 at 5:05 AM wrote:
>
> From: Guo Ren
>
> Highest 10 bits of PTE are reserved in riscv-privileged, ref: [1], so we
> need to ignore them. They cannot be a part of ppn.
>
> 1: The RISC-V Instruction Set Manual, Volume II: Privileged Architecture
>4.4 Sv39: Page-Based 39-bit
On Wed, Sep 25, 2019 at 9:16 AM Guo Ren wrote:
>
> "Bits 63–54 are reserved for future use and must be
> zeroed by software for forward compatibility."
>
> That doesn't mean 63-54 are belong to ppn, it's reserved for future
> and nobody know 63-54 will be part of ppn.
> Current riscv qemu ppn impl
On 9/24/19 11:00 PM, Alex Bennée wrote:
> From: Richard Henderson
>
> This is a bit more straight-forward than using a switch statement.
> No functional change.
>
> Signed-off-by: Richard Henderson
> Signed-off-by: Alex Bennée
> Message-Id: <20190921043256.4575-2-richard.hender...@linaro.org>
On 9/24/19 11:00 PM, Alex Bennée wrote:
> From: Richard Henderson
>
> The CONFIG_USER_ONLY adjustment blindly mashed the swcr
> exception enable bits into the fpcr exception disable bits.
>
> However, fpcr_exc_enable has already converted the exception
> disable bits into the exception status bi
On 9/24/19 11:00 PM, Alex Bennée wrote:
> From: Richard Henderson
>
> Remove a redundant masking of ignore. Once that's gone it is
> obvious that the system-mode inner test is redundant with the
> outer test. Move the fpcr_exc_enable masking up and tidy.
>
> No functional change.
>
> Signed-o
On 9/24/19 11:00 PM, Alex Bennée wrote:
> From: "Dr. David Alan Gilbert"
>
> We've got various places where we wait for a migration to enter
> a given state; but if we enter an unexpected state we tend to fail
> in odd ways; add a mechanism for explicitly testing for any state
> which we shouldn'
On 9/24/19 11:00 PM, Alex Bennée wrote:
> From: John Snow
>
> When it was based on debian8 which uses python-minimal, it needed this.
> It no longer does.
>
> Goodbye, python2.7.
>
> Signed-off-by: John Snow
> Message-Id: <20190918222546.11696-1-js...@redhat.com>
> [AJB: fixed up commit messag
On 9/24/19 11:00 PM, Alex Bennée wrote:
> The slirp sub-module complains about not being able to find the glib
> library on cross-compiles because it is using the default pkg-config
> tool (which isn't installed in our cross-build docker images).
> Preserve PKG_CONFIG in our host config and pass it
On 9/24/19 11:00 PM, Alex Bennée wrote:
> This is broadly similar to the existing fcvt test for ARM but using
> the generic float testing framework. We should be able to pare down
> the ARM fcvt test case to purely half-precision with or without the
> Alt HP provision.
>
> Signed-off-by: Alex Benn
On 9/24/19 11:01 PM, Alex Bennée wrote:
> From: John Snow
>
> debian-sid is listed as a partial image, so we cannot run tests against it.
> Since it isn't used by any other testable image, remove it for now as it
> is prone to bitrot.
>
> Signed-off-by: John Snow
> Message-Id: <20190923181140.7
On 9/24/19 11:01 PM, Alex Bennée wrote:
> From: John Snow
>
> There isn't a debian.dockerfile anymore,
> so perform some ghost-busting.
Won't we deprecate other images in the future?
> Signed-off-by: John Snow
> Message-Id: <20190923181140.7235-4-js...@redhat.com>
> Signed-off-by: Alex Bennée
On 9/24/19 11:01 PM, Alex Bennée wrote:
> From: John Snow
>
> As part of the push to drop python2 support, replace any explicit python2
> dependencies with python3 versions.
>
> For centos, python2 still exists as an implicit dependency, but by adding
> python3 we will be able to build even if t
On 9/24/19 11:01 PM, Alex Bennée wrote:
> From: John Snow
>
> debian-ports is listed as a partial image, so we cannot run tests against it.
> Since it isn't used by any other testable image, remove it for now as it
> is prone to bitrot.
>
> Signed-off-by: John Snow
> Message-Id: <20190923181140
On 9/24/19 11:01 PM, Alex Bennée wrote:
> Despite our attempts in 4d26c7fef4 to keep this going it still gets in
> the way of "make docker-test-build" completing because of course we
> can't build a modern QEMU with the image. Let's put the thing out of
> it's misery and remove it.
>
> People who
On 9/24/19 11:00 PM, Alex Bennée wrote:
> This adds two new tests that re-use the memory test to check basic
> record replay functionality is still working. We have to define our
> own runners rather than using the default pattern as we want to change
> the test name but re-use the memory binary.
>
On 9/24/19 11:00 PM, Alex Bennée wrote:
> This is a generic floating point multiply and accumulate test for
> single precision floating point values. I've split of the common float
> functions into a helper library so additional tests can use the same
> common code.
>
> As I don't have references
On 9/24/19 11:00 PM, Alex Bennée wrote:
> It was pointed out we haven't documented the check-tcg part of the
> build system. Attempt to rectify that now.
>
> Signed-off-by: Alex Bennée
> ---
> docs/devel/testing.rst | 62 ++
> 1 file changed, 62 insertions
Hi Alex,
On 9/24/19 11:00 PM, Alex Bennée wrote:
> Now we have fixed the signal delivary bug we can remove this horrible
"delivery"
> hack from the system.
>
> Cc: Richard Henderson
> Signed-off-by: Alex Bennée
Can you reorder this patch after directly "target/ppc: fix signal
delivery for pp
On Thu, Sep 26, 2019 at 12:07 AM Philippe Mathieu-Daudé
wrote:
> On 9/24/19 11:00 PM, Alex Bennée wrote:
> > These were missed in the recent de-tangling so have been updated to be
> > more actuate. I've also built up ARM_TESTS in a manner similar to
> > AARCH64_TESTS for better consistency.
> >
>
On 9/24/19 11:00 PM, Alex Bennée wrote:
> These were missed in the recent de-tangling so have been updated to be
> more actuate. I've also built up ARM_TESTS in a manner similar to
> AARCH64_TESTS for better consistency.
>
> Signed-off-by: Alex Bennée
> Reviewed-by: Peter Maydell
> ---
> tests/
The CPUID bits CLZERO and XSAVEERPTR are availble on AMD's ZEN platform
and could be passed to the guest.
Signed-off-by: Sebastian Andrzej Siewior
---
I tweaked the kernel to expose these flags and figured out that this is
also missing in order see those bits in the guest.
target/i386/cpu.c |
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 63 -
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 6d4e9eb348..a53d5d1916 100644
--- a/crypto/blo
This is just to make qcrypto_block_luks_open more
reasonable in size.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 223 +---
1 file changed, 125 insertions(+), 98 deletions(-)
diff --git a/crypto/block-luks.c b/
Currently if you attampt to create too large file with luks you
get the following error message:
Formatting 'test.luks', fmt=luks size=17592186044416 key-secret=sec0
qemu-img: test.luks: Could not resize file: File too large
While for raw format the error message is
qemu-img: test.img: The image
These values are not used by generic crypto code anyway
Signed-off-by: Maxim Levitsky
---
crypto/block-luks.c | 45 +
1 file changed, 13 insertions(+), 32 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index f3bfc921b2..b8f9b9c20a
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 155 ++--
1 file changed, 93 insertions(+), 62 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index b8f9b9c20a..47371edf13 100644
--- a/crypto/blo
This function will be used later to store
new keys to the luks metadata
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 304 ++--
1 file changed, 181 insertions(+), 123 deletions(-)
diff --git a/crypto/block-luks.c
Another minor refactoring
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 9e59a791a6..b759cc8d19 100644
--- a/crypto/block-luks.c
+++ b
Prior to that patch, the parsed encryption settings
were already stored into the QCryptoBlockLUKS but not
used anywhere but in qcrypto_block_luks_get_info
Using them simplifies the code
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 169
Check that keyslots don't overlap with the data,
and check that keyslots don't overlap with each other.
(this is done using naive O(n^2) nested loops,
but since there are just 8 keyslots, this doesn't really matter.
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-
* key_bytes -> master_key_len
* payload_offset = payload_offset_sector (to emphasise that this isn't byte
offset)
* key_offset -> key_offset_sector - same as above for luks slots
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 91 +++-
Let the caller allocate masterkey
Always use master key len from the header
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 44 +---
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/crypto/block-luks.
This way we can store the header we loaded, which
will be used in key management code
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
crypto/block-luks.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
inde
Hi!
This patch series is the refactoring/preparation part of the
former patch series I had sent which adds support for luks
key management.
V2:
I addressed all the review comments
I also added another minor patch to improve an error messsage
when trying to create too large file, for which I have
* rename the write_func to create_write_func,
and init_func to create_init_func
this is preparation for other write_func that will
be used to update the encryption keys.
No functional changes
Signed-off-by: Maxim Levitsky
Reviewed-by: Daniel P. Berrangé
---
block/crypto.c | 12 ++---
On 9/25/19 1:32 PM, Max Reitz wrote:
125 should not use qemu-img to get the on-disk image size, because that
reports it in a human-readable format that is useless to us. Just use
stat instead (like we do to get the image file length).
Signed-off-by: Max Reitz
---
tests/qemu-iotests/125 | 3 +
> Did you see the follow up email indicating the typo that I found in
patch 6?
I did, then forgot to include it in my build. I've included that change
now...
> Does that help any more tests to pass?
I'm down from 22 failures to 8.
--
You received this bug notification because you are a member
On 9/25/19 1:32 PM, Max Reitz wrote:
If we use growth_mode = metadata, it is very much possible that the file
uses more disk space after we have written something to the added area.
We did indeed want to test for this case, but unfortunately we evidently
just copied the code from the "Test creati
On 9/25/19 1:32 PM, Max Reitz wrote:
And by that I mean all XFS versions, as far as I can tell. All details
are in the comment below.
We never noticed this problem because we only read the first number from
qemu-img info's "disk size" output -- and that is effectively useless,
because qemu-img
On 9/25/19 4:03 PM, Tomáš Golembiovský wrote:
Add command for reporting devices on Windows guest. The intent is not so
much to report the devices but more importantly the driver (and its
version) that is assigned to the device. This gives caller the
information whether VirtIO drivers are installe
Philippe Mathieu-Daudé writes:
> Hi Alex,
>
> On 9/24/19 11:00 PM, Alex Bennée wrote:
>> From: Philippe Mathieu-Daudé
>>
>> To build WHPX (Windows Hypervisor) binaries, we need the WHPX
>> headers provided by the Windows SDK.
>
> Justin is checking with his company if this patch is OK with the
Add command for reporting devices on Windows guest. The intent is not so
much to report the devices but more importantly the driver (and its
version) that is assigned to the device. This gives caller the
information whether VirtIO drivers are installed and/or whether
inadequate driver is used on a
Add command for reporting devices on Windows guest. The intent is not so
much to report the devices but more importantly the driver (and its
version) that is assigned to the device. This gives caller the
information whether VirtIO drivers are installed and/or whether
inadequate driver is used on a
Hi Thomas,
On 9/25/19 3:03 PM, Thomas Huth wrote:
> Both, "rom->addr" and "addr" are derived from the binary image
> that can be loaded with the "-kernel" paramer. The code in
> rom_copy() then calculates:
>
> d = dest + (rom->addr - addr);
>
> and uses "d" as destination in a memcpy() some
On 24/09/2019 22:46, Richard Henderson wrote:
> On 9/24/19 8:35 AM, Mark Cave-Ayland wrote:
>> Switch over all accesses to the decimal numbers held in struct PPC_DFP from
>> using HI_IDX and LO_IDX to using the VsrD() macro instead. Not only does this
>> allow the compiler to ensure that the vario
On 9/25/19 7:06 AM, Sam Eiderman via wrote:
> v1:
>
> Non-standard logical geometries break under QEMU.
>
> A virtual disk which contains an operating system which depends on
> logical geometries (consistent values being reported from BIOS INT13
> AH=08) will most likely break under QEMU/SeaBI
On Wed, 25 Sep 2019 16:45:26 +1000
David Gibson wrote:
> Currently spapr_qirq() used to find the qemu_irq for an spapr global irq
> number, redirects through the SpaprIrq::qirq method. But the array of
> qemu_irqs is allocated in the PAPR layer, not the backends, and so the
> method implementati
Hi Alex,
On 9/24/19 11:00 PM, Alex Bennée wrote:
> From: Philippe Mathieu-Daudé
>
> To build WHPX (Windows Hypervisor) binaries, we need the WHPX
> headers provided by the Windows SDK.
Justin is checking with his company if this patch is OK with them,
I'd rather wait before merging it:
https://
On Wed, 25 Sep 2019 16:45:25 +1000
David Gibson wrote:
> spapr global irq numbers are different from the source numbers on the ICS
> when using XICS - they're offset by XICS_IRQ_BASE (0x1000). But
> spapr_irq_set_irq_xics() was passing through the global irq number to
> the ICS code unmodified.
On Tue, Sep 24, 2019 at 08:35:13AM +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 23, 2019 at 04:05:33PM -0300, Eduardo Habkost wrote:
[...]
> > Even for other long-lifetime distros, I really think "2 years
> > after the new major version is released" is too long, and I'd
> > like to shorten this t
On 25.09.19 19:55, Richard Henderson wrote:
> On 9/24/19 12:59 AM, David Hildenbrand wrote:
>>> +is_ram = memory_region_is_ram(section->mr);
>>> +is_romd = memory_region_is_romd(section->mr);
>>> +
>>> +if (is_ram || is_romd) {
>>> +/* RAM and ROMD both have associated host memo
On 25.09.19 21:25, Richard Henderson wrote:
> On 9/25/19 5:52 AM, David Hildenbrand wrote:
>> +static inline int read_table_entry(hwaddr gaddr, uint64_t *entry)
>> +{
>> +/*
>> + * According to the PoP, these table addresses are "unpredictably real
>> + * or absolute". Also, "it is unpr
On 9/25/19 5:52 AM, David Hildenbrand wrote:
> While ASCE_ORIGIN is not wrong, it is certainly confusing. We want a
> page frame address.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mmu_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
ops, I've sent unfinished message
On 25.09.2019 22:19, Vladimir Sementsov-Ogievskiy wrote:
> Ogh :(
>
> And I realized that there is bigger problem with design:
>
> Assume failed copy in filter request: we want to mark bits dirty again
> and release range lock on source.. But if we have some wri
On 9/25/19 5:52 AM, David Hildenbrand wrote:
> Let's return the PGM from the translation functions on error and inject
> based on that.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mmu_helper.c | 63 +++
> 1 file changed, 17 insertions(+), 46 dele
Ogh :(
And I realized that there is bigger problem with design:
Assume failed copy in filter request: we want to mark bits dirty again
and release range lock on source.. But if we have some write reguests
in parallel, they may already passed backup-top filter, and they are
only waiting for range
On 9/25/19 5:52 AM, David Hildenbrand wrote:
> +static inline int read_table_entry(hwaddr gaddr, uint64_t *entry)
> +{
> +/*
> + * According to the PoP, these table addresses are "unpredictably real
> + * or absolute". Also, "it is unpredictable whether the address wraps
> + * or an
On 9/25/19 5:52 AM, David Hildenbrand wrote:
> Let's get it out of the way to make some further refactorings easier.
> Personally, I've never used these debug statements at all. And if I had
> to debug issue, I used plain GDB instead (debug prints are just way too
> much noise in the MMU). We might
On 9/25/19 5:52 AM, David Hildenbrand wrote:
> We'll reuse the ilen and tec definitions in mmu_translate
> soon also for all other DAT exceptions we inject. Move it to the caller,
> where we can later pair it up with other protection checks, like IEP.
>
> Signed-off-by: David Hildenbrand
> ---
>
On Tue, 24 Sep 2019 23:04:22 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, September 25, 2019 2:03 AM
> >
> > On Tue, 24 Sep 2019 02:19:15 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Tian, Kevin
> > > > Sent: Friday, Septem
On 9/24/19 2:00 PM, Alex Bennée wrote:
> It was pointed out we haven't documented the check-tcg part of the
> build system. Attempt to rectify that now.
>
> Signed-off-by: Alex Bennée
> ---
> docs/devel/testing.rst | 62 ++
> 1 file changed, 62 insertions(
That certainly sounds like progress. Did you see the follow up email
indicating the typo that I found in patch 6? It can be fixed by applying
the following diff on top:
diff --git a/target/ppc/dfp_helper.c b/target/ppc/dfp_helper.c
index c2d335e928..b801acbedc 100644
--- a/target/ppc/dfp_helper.c
On 9/24/19 2:01 PM, Alex Bennée wrote:
> Despite our attempts in 4d26c7fef4 to keep this going it still gets in
> the way of "make docker-test-build" completing because of course we
> can't build a modern QEMU with the image. Let's put the thing out of
> it's misery and remove it.
>
> People who r
Fixes the previous TLB_WATCHPOINT patches because we are currently
failing to set cpu->mem_io_pc with the call to cpu_check_watchpoint.
Pass down the retaddr directly because it's readily available.
Fixes: 50b107c5d61
Reviewed-by: Alex Bennée
Reviewed-by: David Hildenbrand
Signed-off-by: Richard
On 25/09/2019 19:52, Mark Cave-Ayland wrote:
> On 23/09/2019 23:59, Richard Henderson wrote:
>
>> Changes since v3:
>> * Don't accidentally include the TARGET_PAGE_BITS_VARY patch set. ;-)
>> * Remove __has_attribute(__always_inline__).
>> * Use single load/store_memop function instead of
1 - 100 of 402 matches
Mail list logo
