On Thu, 5 Dec 2019 11:49:00 +0530
Kirti Wankhede wrote:
> On 12/5/2019 11:26 AM, Alex Williamson wrote:
> > On Thu, 5 Dec 2019 11:12:23 +0530
> > Kirti Wankhede wrote:
> >
> >> On 12/5/2019 6:58 AM, Yan Zhao wrote:
> >>> On Thu, Dec 05, 2019 at 02:34:57AM +0800, Alex Williamson wrote:
> >
Hi:
On 2019/12/5 上午11:24, Yan Zhao wrote:
For SRIOV devices, VFs are passthroughed into guest directly without host
driver mediation. However, when VMs migrating with passthroughed VFs,
dynamic host mediation is required to (1) get device states, (2) get
dirty pages. Since device states as well
On 12/5/2019 11:26 AM, Alex Williamson wrote:
On Thu, 5 Dec 2019 11:12:23 +0530
Kirti Wankhede wrote:
On 12/5/2019 6:58 AM, Yan Zhao wrote:
On Thu, Dec 05, 2019 at 02:34:57AM +0800, Alex Williamson wrote:
On Wed, 4 Dec 2019 23:40:25 +0530
Kirti Wankhede wrote:
On 12/3/2019 11:34 PM,
Hi,
I was wondering if this is going anywhere or if SLOF is still expected
to get fixed and if it is SLOF, then what exactly in SLOF's behaviour is
incorrect and requires fixing? I am a bit lost here. Thanks,
On 20/11/2019 11:50, Michael Roth wrote:
> Currently the SLOF firmware for pseries gu
On Thu, 5 Dec 2019 11:12:23 +0530
Kirti Wankhede wrote:
> On 12/5/2019 6:58 AM, Yan Zhao wrote:
> > On Thu, Dec 05, 2019 at 02:34:57AM +0800, Alex Williamson wrote:
> >> On Wed, 4 Dec 2019 23:40:25 +0530
> >> Kirti Wankhede wrote:
> >>
> >>> On 12/3/2019 11:34 PM, Alex Williamson wrote:
>
On Thu, Dec 05, 2019 at 01:42:23PM +0800, Kirti Wankhede wrote:
>
>
> On 12/5/2019 6:58 AM, Yan Zhao wrote:
> > On Thu, Dec 05, 2019 at 02:34:57AM +0800, Alex Williamson wrote:
> >> On Wed, 4 Dec 2019 23:40:25 +0530
> >> Kirti Wankhede wrote:
> >>
> >>> On 12/3/2019 11:34 PM, Alex Williamson wro
On 12/5/2019 6:58 AM, Yan Zhao wrote:
On Thu, Dec 05, 2019 at 02:34:57AM +0800, Alex Williamson wrote:
On Wed, 4 Dec 2019 23:40:25 +0530
Kirti Wankhede wrote:
On 12/3/2019 11:34 PM, Alex Williamson wrote:
On Mon, 25 Nov 2019 19:57:39 -0500
Yan Zhao wrote:
On Fri, Nov 15, 2019 at 05:
On 11/19/19 8:15 AM, David Gibson wrote:
On Thu, Oct 24, 2019 at 01:13:06PM +0530, Ganesh Goudar wrote:
From: Aravinda Prasad
This patch includes migration support for machine check
handling. Especially this patch blocks VM migration
requests until the machine check error handling is
complet
On Tue, Dec 03, 2019 at 05:54:38PM +, Peter Maydell wrote:
> On Mon, 2 Dec 2019 at 14:06, Cleber Rosa wrote:
> >
> > RFC: QEMU Gating CI
> > ===
> >
> > This RFC attempts to address most of the issues described in
> > "Requirements/GatinCI"[1]. An also relevant write up is the
On Wed, 4 Dec 2019, at 03:57, Philippe Mathieu-Daudé wrote:
> On 12/3/19 1:48 PM, Andrew Jeffery wrote:
> > On Tue, 3 Dec 2019, at 16:39, Philippe Mathieu-Daudé wrote:
> >> On 12/3/19 5:14 AM, Andrew Jeffery wrote:
> >>> Prepare for SoCs such as the ASPEED AST2600 whose firmware configures
> >>>
On 11/19/19 8:09 AM, David Gibson wrote:
On Thu, Oct 24, 2019 at 01:13:05PM +0530, Ganesh Goudar wrote:
From: Aravinda Prasad
This patch adds support in QEMU to handle "ibm,nmi-register"
and "ibm,nmi-interlock" RTAS calls.
The machine check notification address is saved when the
OS issues "
>
> On 2019/12/4 16:33, Pankaj Gupta wrote:
> >
> >> From: Pan Nengyuan
> >>
> >> Devices tend to maintain vq pointers, allow deleting them trough a vq
> >> pointer.
> >>
> >> Signed-off-by: Michael S. Tsirkin
> >> Signed-off-by: Pan Nengyuan
> >> ---
> >> Changes v2 to v1:
> >> - add a new
On 04/12/2019 21:32, Laurent Vivier wrote:
> On 04/12/2019 05:40, Alexey Kardashevskiy wrote:
>>
>>
>> On 04/12/2019 15:23, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 04/12/2019 03:09, Laurent Vivier wrote:
Bad reply, the problem is with
"spapr: Render full FDT on ibm,client-
add a 'disablable' flag to each each sparse mmaped region and this flag is by
default off.
vfio_region_disablable_mmaps_set_enabled() will enable/disable mmapped
subregions if its 'disablable' flag is on.
Cc: Kevin Tian
Signed-off-by: Yan Zhao
---
hw/vfio/common.c | 28 +++
This patchset enables PCI BARs to be dynamically trapped/passthroughed
in response to vendor driver's needs.
To dynamic trap/untrap PCI BARs, 3 info required:
(1) which part of PCI BARs are to be trapped/passthroughed
(2) when to do the trap/passthrough transition
(3) to trap or to passthrough
Pa
for devices that support device region of type
VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and subtype
VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO, probe and init a
dynamic-trap-bar-info region which holds info of
(1) fd of eventfd,
(2) to trap/untrap of sparse mmaped pci bars.
Vendor driver first should
From: Pan Nengyuan
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of
From: Pan Nengyuan
The BDRVNBDState cleanup code is common in two places, add
nbd_clear_bdrvstate() function to do these cleanups.
Signed-off-by: Stefano Garzarella
Signed-off-by: Pan Nengyuan
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
v3:
- new patch, split form 2/2 patch (suggested by St
From: Pan Nengyuan
This series add a new function to do the common cleanups, and fix a memory
leak in nbd_open when nbd_client_connect returns error status.
---
Changes v2 to v1:
- add a new function to do the common cleanups (suggested by Stefano
Garzarella).
---
Changes v3 to v2:
- split in t
This sample code first returns device
cap |= VFIO_PCI_DEVICE_CAP_DYNAMIC_TRAP_BAR, so that vfio-pci driver
would create for it a dynamic-trap-bar-info region
(of type VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and
subtype VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO)
Then in igd_dt_get_region_info(), thi
in vfio_pci_mediate_ops->get_region_info(), migration region's len and
flags are overridden and its region index is saved.
vfio_pci_mediate_ops->rw() and vfio_pci_mediate_ops->mmap() overrides
default rw/mmap for migration region.
This is only a sample implementation in i440 vf migration to demon
Vendor driver specifies when to support a migration region through cap
VFIO_PCI_DEVICE_CAP_MIGRATION in vfio_pci_mediate_ops->open().
If vfio-pci detects this cap, it creates a default migration region on
behalf of vendor driver with region len=0 and region->ops=null.
Vendor driver should override
This is a sample driver to use mediate ops for passthrough IGDs.
This sample driver does not directly bind to IGD device but defines what
IGD devices to support via a pciidlist.
It registers its vfio_pci_mediate_ops to vfio-pci on driver loading.
when vfio_pci->open() calls vfio_pci_mediate_ops-
register to vfio-pci vfio_pci_mediate_ops when i40e binds to PF to
support mediating of VF's vfio-pci ops.
unregister vfio_pci_mediate_ops when i40e unbinds from PF.
vfio_pci_mediate_ops->open will return success if the device passed in
equals to devfn of its VFs
Cc: Shaopeng He
Signed-off-by:
For regions registered through vfio_pci_register_dev_region(),
before calling region->ops, first check whether region->ops is not null.
As in the next two patches, dev regions of null region->ops are to be
registered by default on behalf of vendor driver, we need to check here
to prevent null poin
Dynamic trap bar info region is a channel for QEMU and vendor driver to
communicate dynamic trap info. It is of type
VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and subtype
VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO.
This region has two fields: dt_fd and trap.
When QEMU detects a device regions of this
when vfio-pci is bound to a physical device, almost all the hardware
resources are passthroughed.
Sometimes, vendor driver of this physcial device may want to mediate some
hardware resource access for a short period of time, e.g. dirty page
tracking during live migration.
Here we introduce mediate
From: Pan Nengyuan
The BDRVNBDState cleanup code is common in two places, add
nbd_clear_bdrvstate() function to do these cleanups.
Signed-off-by: Stefano Garzarella
Signed-off-by: Pan Nengyuan
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
v3:
- new patch, split form 2/2 patch (suggested by St
mediate dynamic_trap_info region to dynamically trap bar0.
bar0 is sparsely mmaped into 5 sub-regions, of which only two need to be
dynamically trapped.
By mediating dynamic_trap_info region and telling QEMU this information,
the two sub-regions of bar0 can be trapped when migration starts and put
For SRIOV devices, VFs are passthroughed into guest directly without host
driver mediation. However, when VMs migrating with passthroughed VFs,
dynamic host mediation is required to (1) get device states, (2) get
dirty pages. Since device states as well as other critical information
required for d
From: Pan Nengyuan
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of
From: Pan Nengyuan
This series add a new function to do the common cleanups, and fix a memory
leak in nbd_open when nbd_client_connect returns error status.
---
Changes v2 to v1:
- add a new function to do the common cleanups (suggested by Stefano
Garzarella).
---
Changes v3 to v2:
- split in t
OK. Updated in version 2.
On Wed, Dec 4, 2019 at 8:21 PM Dr. David Alan Gilbert
wrote:
> * Han Han (h...@redhat.com) wrote:
> > This reverts commit bbd9e6985ff342cbe15b9cb7eb30e842796fbbe8.
>
> Patchew spotted you're missing the signed-off-by; please send one.
>
> Dave
>
> > In 20a1922032 we all
This reverts commit bbd9e6985ff342cbe15b9cb7eb30e842796fbbe8.
In 20a1922032 we allowed reboot-timeout=-1 again, so update the doc
accordingly.
Signed-off-by: Han Han
---
qemu-options.hx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
ind
On 2019/12/4 22:40, Eric Blake wrote:
> On 12/4/19 1:31 AM, pannengy...@huawei.com wrote:
>> From: Pan Nengyuan
>>
>> Devices tend to maintain vq pointers, allow deleting them trough a vq
>> pointer.
>
> through
Thanks. I'm sorry for my carelessness.
>
>>
>> Signed-off-by: Michael S. Tsirki
On 2019/12/4 16:33, Pankaj Gupta wrote:
>
>> From: Pan Nengyuan
>>
>> Devices tend to maintain vq pointers, allow deleting them trough a vq
>> pointer.
>>
>> Signed-off-by: Michael S. Tsirkin
>> Signed-off-by: Pan Nengyuan
>> ---
>> Changes v2 to v1:
>> - add a new function virtio_delete_que
Parse input string both as a double and as a uint64_t, then use the
method which consumes more characters. Update the related test cases.
Signed-off-by: Tao Xu
---
tests/test-cutils.c| 37 -
tests/test-keyval.c| 47 ---
tests/test-qemu-opts.c |
On Thu, Dec 05, 2019 at 02:34:57AM +0800, Alex Williamson wrote:
> On Wed, 4 Dec 2019 23:40:25 +0530
> Kirti Wankhede wrote:
>
> > On 12/3/2019 11:34 PM, Alex Williamson wrote:
> > > On Mon, 25 Nov 2019 19:57:39 -0500
> > > Yan Zhao wrote:
> > >
> > >> On Fri, Nov 15, 2019 at 05:06:25AM +0800
>
> On Thu, Nov 28, 2019 at 08:44:43AM +, Wangyong wrote:
> > Hi all,
>
> This looks interesting, please continue this discussion on the QEMU mailing
> list
> so that others can participate.
>
> >
> > This patch makes virtio_blk queue size configurable
> >
> > commit 6040aedddb5f474a9c2304b6a
On Thu, Nov 21, 2019 at 4:59 PM Tomasz Figa wrote:
>
> On Thu, Nov 21, 2019 at 6:41 AM Geoffrey McRae wrote:
> >
> >
> >
> > On 2019-11-20 23:13, Tomasz Figa wrote:
> > > Hi Geoffrey,
> > >
> > > On Thu, Nov 7, 2019 at 7:28 AM Geoffrey McRae
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 2019-11-06
On Wed, Dec 04, 2019 at 04:46:12PM +0100, Thomas Huth wrote:
> Some tests create huge (but sparse) files, and to be able to run those
> tests in certain limited environments (like CI containers), we have to
> check for the possibility to create such files first. Thus let's introduce
> a common func
Commit 34ea023d4b9 introduced the Tulip PCI NIC.
Since this better models the DP264 hardware, use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/alpha/dp264.c | 4 ++--
hw/alpha/Kconfig | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
i
Richard Henderson writes:
> On 12/4/19 10:58 AM, Alex Bennée wrote:
>>> @@ -7437,13 +7437,10 @@ void define_one_arm_cp_reg_with_opaque(ARMCPU *cpu,
>>> mask = PL0_RW;
>>> break;
>>> case 4:
>>> +case 5:
>>> /* min_EL EL2 */
>>>
On Wed, Dec 04, 2019 at 04:49:15PM +, Dr. David Alan Gilbert wrote:
> * Scott Cheloha (chel...@linux.vnet.ibm.com) wrote:
> > On Mon, Oct 21, 2019 at 09:14:44AM +0100, Dr. David Alan Gilbert wrote:
> > > * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > > > On Fri, Oct 18, 2019 at 10:43:5
On Wed, Dec 04, 2019 at 04:46:18PM +0100, Thomas Huth wrote:
> Travis recently added the possibility to test on these architectures,
> too, so let's enable them in our travis.yml file to extend our test
> coverage.
>
> Unfortunately, the libssh in this Ubuntu version (bionic) is in a pretty
> unus
Centos 7.7 only provides cross GCC 4.8.5, but the script forces
us to use GCC5. Since the same machinery is valid to check the
GCC version, remove the $emulation_target check.
$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
$ aarch64-linux-gnu-gcc -v 2>&1 | tail -1
gcc vers
Hello Philippe,
On Wed, Dec 4, 2019 at 5:53 PM Philippe Mathieu-Daudé
wrote:
> Hi Niek,
>
> On 12/2/19 10:09 PM, Niek Linnenbank wrote:
> > The Allwinner H3 is a System on Chip containing four ARM Cortex A7
> > processor cores. Features and specifications include DDR2/DDR3 memory,
> > SD/MMC sto
On 12/4/19 5:40 PM, Damien Hedde wrote:
On 12/2/19 5:15 PM, Peter Maydell wrote:
The one topic I think we could do with discussing is whether
a simple uint64_t giving the frequency of the clock in Hz is
the right representation. In particular in your patch 9 the
board has a clock frequency that
On Wed, Dec 4, 2019 at 5:11 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Monday, December 2, 2019, Niek Linnenbank
> wrote:
>
>> The Allwinner H3 System on Chip contains multiple USB 2.0 bus
>> connections which provide software access using the Enhanced
>> Host Controlle
On Wed, Dec 04, 2019 at 04:46:11PM +0100, Thomas Huth wrote:
> Travis recently added build hosts for arm64, ppc64le and s390x, so
> this is a welcome addition to our Travis testing matrix.
>
> Unfortunately, the builds are running in quite restricted LXD containers
> there, for example it is not p
On Wed, Dec 4, 2019 at 10:03 AM Philippe Mathieu-Daudé
wrote:
> On 12/3/19 8:33 PM, Niek Linnenbank wrote:
> > Hello Philippe,
> >
> > Thanks for your quick review comments!
> > I'll start working on a v2 of the patches and include the changes you
> > suggested.
>
> Thanks, but I'd suggest to wai
On 12/4/19 10:58 AM, Alex Bennée wrote:
>> @@ -7437,13 +7437,10 @@ void define_one_arm_cp_reg_with_opaque(ARMCPU *cpu,
>> mask = PL0_RW;
>> break;
>> case 4:
>> +case 5:
>> /* min_EL EL2 */
>> mask = PL2_RW;
>> break;
The power7_set_irq() and power9_set_irq() functions set this but it is
never used actually. Modern Book3s compatible CPUs are only supported
by the pnv and spapr machines. They have an interrupt controller, XICS
for POWER7/8 and XIVE for POWER9, whose models don't require to track
IRQ input states
This only makes sense with an emulated CPU. Don't set the bit in
CPUState::interrupt_request when using KVM to avoid confusions.
Signed-off-by: Greg Kurz
---
target/ppc/helper_regs.h |5 +
1 file changed, 5 insertions(+)
diff --git a/target/ppc/helper_regs.h b/target/ppc/helper_regs.h
i
The correct way to do this is to deassert the input pins on the CPU side.
This is the case since a previous change.
Signed-off-by: Greg Kurz
---
hw/intc/xics.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 0b259a09c545..1952009e6d22 100644
--- a/h
When a CPU is reset, QEMU makes sure no interrupt is pending by clearing
CPUPPCstate::pending_interrupts in ppc_cpu_reset(). In the case of a
complete machine emulation, eg. a sPAPR machine, an external interrupt
request could still be pending in KVM though, eg. an IPI. It will be
eventually presen
Guest hangs have been observed recently on POWER9 hosts, specifically LC92x
"Boston" systems, when the guests are being rebooted multiple times. The
issue isn't POWER9 specific though. It is caused by a very long standing bug
when using the uncommon accel=kvm,kernel-irqchip=off machine configuratio
* Vivek Goyal (vgo...@redhat.com) wrote:
> There are some unused fields in "struct fv_QueueInfo". Get rid of these
> fields.
>
> Signed-off-by: Vivek Goyal
> ---
> contrib/virtiofsd/fuse_virtio.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/contrib/virtiofsd/fuse_virtio.c b/co
As of now we don't support fcntl(F_SETLKW) and if we see one, we return
-EOPNOTSUPP.
Change that by accepting these requests and returning a reply immediately
asking caller to wait. Once lock is available, send a notification to
the waiter indicating lock is available.
Signed-off-by: Vivek Goyal
Add a notification queue which will be used to send async notifications
for file lock availability.
Signed-off-by: Vivek Goyal
---
contrib/virtiofsd/fuse_i.h | 1 +
contrib/virtiofsd/fuse_virtio.c| 74 +++---
hw/virtio/vhost-user-fs-pci.c
There are some unused fields in "struct fv_QueueInfo". Get rid of these fields.
Signed-off-by: Vivek Goyal
---
contrib/virtiofsd/fuse_virtio.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/contrib/virtiofsd/fuse_virtio.c b/contrib/virtiofsd/fuse_virtio.c
index 31c8542b6c..2a9cd60a01 1
Hi,
Here is V2 of RFC patches for adding a notification queue to
vhost-user-fs device to send notifications from host to guest.
It also has patches to support remote posix locks which make use of this
newly introduced notification queue.
I have taken care of most of the comments from last iterati
Daemon specifies size of notification buffer needed and that should be done
using config space.
Only ->notify_buf_size value of config space comes from daemon. Rest of
it is filled by qemu device emulation code.
Signed-off-by: Vivek Goyal
---
contrib/virtiofsd/fuse_virtio.c| 31
We are emulating posix locks for guest using open file description locks
in virtiofsd. When any of the fd is closed in guest, we find associated
OFD lock fd (if there is one) and close it to release all the locks.
Assumption here is that there is no other thread using lo_inode_plock
structure or p
Richard Henderson writes:
> For ARMv8.1, op1 == 5 is reserved for EL2 aliases of
> EL1 and EL0 registers.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> i
On Wed, Dec 04, 2019 at 05:21:25PM +0100, Jens Freimann wrote:
> On Wed, Dec 04, 2019 at 11:35:37AM -0300, Eduardo Habkost wrote:
> > On Wed, Dec 04, 2019 at 10:18:24AM +0100, Jens Freimann wrote:
> > > On Tue, Dec 03, 2019 at 06:40:04PM -0300, Eduardo Habkost wrote:
> > > > +jfreimann, +mst
> > >
Richard Henderson writes:
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> target/arm/helper.c | 102 +++-
> 1 file changed, 81 insertions(+), 21 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index a4a7f
On Wed, 4 Dec 2019 23:40:25 +0530
Kirti Wankhede wrote:
> On 12/3/2019 11:34 PM, Alex Williamson wrote:
> > On Mon, 25 Nov 2019 19:57:39 -0500
> > Yan Zhao wrote:
> >
> >> On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
> >>> On Fri, 15 Nov 2019 00:26:07 +0530
> >>> Kirti W
On 12/3/2019 11:34 PM, Alex Williamson wrote:
On Mon, 25 Nov 2019 19:57:39 -0500
Yan Zhao wrote:
On Fri, Nov 15, 2019 at 05:06:25AM +0800, Alex Williamson wrote:
On Fri, 15 Nov 2019 00:26:07 +0530
Kirti Wankhede wrote:
On 11/14/2019 1:37 AM, Alex Williamson wrote:
On Thu, 14 Nov 201
Document work-flows for
* finding a CPU with pending 'insert/remove' event
* enumerating present and possible CPUs
Signed-off-by: Igor Mammedov
---
docs/specs/acpi_cpu_hotplug.txt | 29 +
1 file changed, 29 insertions(+)
diff --git a/docs/specs/acpi_cpu_hotplug.t
* Move reserved registers to the top of the section, so reader would be
aware of effects when reading registers description.
* State registers endianness explicitly at the beginning of the section
* Describe registers behavior in case of 'CPU selector' register contains
value that doesn't point
Write section of 'Command data' register should describe what happens
when it's written into. Correct description in case the last stored
'Command field' value equals to 0, to reflect that currently it's not
supported.
Signed-off-by: Igor Mammedov
---
docs/specs/acpi_cpu_hotplug.txt | 3 +--
1 f
Correct returned value description in case 'Command field' == 0x0,
it's in not PXM but CPU selector value with pending event
In addition describe 0 blanket value in case of not supported
'Command field' value.
Signed-off-by: Igor Mammedov
---
docs/specs/acpi_cpu_hotplug.txt | 11 +--
1
test lockable SMRAM at default SMBASE feature, introduced by
patch "q35: implement 128K SMRAM at default SMBASE address"
Signed-off-by: Igor Mammedov
---
tests/q35-test.c | 105 +++
1 file changed, 105 insertions(+)
diff --git a/tests/q35-test
Use commit (2f295167e0 q35/mch: implement extended TSEG sizes) for
inspiration and (ab)use reserved register in config space at 0x9c
offset [*] to extend q35 pci-host with ability to use 128K at
0x3 as SMRAM and hide it (like TSEG) from non-SMM context.
Usage:
1: write 0xff in the register
Describe how to enable and detect modern CPU hotplug interface.
Detection part is based on new CPHP_GET_CPU_ID_CMD command,
introduced by "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command" patch.
Signed-off-by: Igor Mammedov
---
docs/specs/acpi_cpu_hotplug.txt | 22 --
1 file cha
Series consists of 2 parts: 1st is lockable SMRAM at SMBASE
and the 2nd adds means to enumerate APIC IDs for possible CPUs.
1st part [1-2/8]:
In order to support CPU hotplug in secure boot mode,
UEFI firmware needs to relocate SMI handler of hotplugged CPU,
in a way that won't allow ring 0 user
Extend CPU hotplug interface to return architecture specific
identifier for current CPU in 2 registers:
- lower 32 bits existing ACPI_CPU_CMD_DATA_OFFSET_RW
- upper 32 bits in new ACPI_CPU_CMD_DATA2_OFFSET_R at
offset 0.
Target user is UEFI firmware, which needs a way to enumerate
all CPUs (i
Hi Niek,
On 12/2/19 10:09 PM, Niek Linnenbank wrote:
The Allwinner H3 is a System on Chip containing four ARM Cortex A7
processor cores. Features and specifications include DDR2/DDR3 memory,
SD/MMC storage cards, 10/100/1000Mbit ethernet, USB 2.0, HDMI and
various I/O modules. This commit adds s
* Scott Cheloha (chel...@linux.vnet.ibm.com) wrote:
> On Mon, Oct 21, 2019 at 09:14:44AM +0100, Dr. David Alan Gilbert wrote:
> > * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > > On Fri, Oct 18, 2019 at 10:43:52AM +0100, Dr. David Alan Gilbert wrote:
> > > > * Laurent Vivier (lviv...@redha
On 12/2/19 5:15 PM, Peter Maydell wrote:
>
> The one topic I think we could do with discussing is whether
> a simple uint64_t giving the frequency of the clock in Hz is
> the right representation. In particular in your patch 9 the
> board has a clock frequency that's not a nice integer number
>
* Scott Cheloha (chel...@linux.vnet.ibm.com) wrote:
> Create a function to abstract common logic needed when removing a
> SaveStateEntry element from the savevm_state.handlers queue.
>
> For now we just remove the element. Soon it will involve additional
> cleanup.
>
> Signed-off-by: Scott Chelo
* Scott Cheloha (chel...@linux.vnet.ibm.com) wrote:
> savevm_state's SaveStateEntry TAILQ is a priority queue. Priority
> sorting is maintained by searching from head to tail for a suitable
> insertion spot. Insertion is thus an O(n) operation.
>
> If we instead keep track of the head of each pr
We seem to be settling out to either fsdev/virtiofsd or tools/virtiofsd
with tools picking up some speed as people seem to want to put a bunch
of other stuff in there.
Unless anyone shouts really loud, I'll work on making it
tools/virtiofsd.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com /
On Wed, Dec 4, 2019 at 5:27 PM Thomas Huth wrote:
>
> On 30/09/2019 19.10, Thomas Huth wrote:
> > This file hasn't seen a real (non-trivial) update since 2008 anymore,
> > so we can assume that it is pretty much out of date and nobody cares
> > for it anymore. Let's simply remove it.
> >
> > Signe
On Wed, Dec 04, 2019 at 11:35:37AM -0300, Eduardo Habkost wrote:
On Wed, Dec 04, 2019 at 10:18:24AM +0100, Jens Freimann wrote:
On Tue, Dec 03, 2019 at 06:40:04PM -0300, Eduardo Habkost wrote:
> +jfreimann, +mst
>
> On Sat, Nov 30, 2019 at 11:10:19AM +, Peter Maydell wrote:
> > On Fri, 29 No
On 30/09/2019 19.10, Thomas Huth wrote:
> This file hasn't seen a real (non-trivial) update since 2008 anymore,
> so we can assume that it is pretty much out of date and nobody cares
> for it anymore. Let's simply remove it.
>
> Signed-off-by: Thomas Huth
> ---
> target/sparc/TODO | 88 -
On 12/4/19 7:53 AM, Alex Bennée wrote:
>
> Richard Henderson writes:
>
>> On 12/4/19 3:43 AM, Alex Bennée wrote:
>
void gen_intermediate_code(CPUState *cpu, TranslationBlock *tb, int
max_insns)
{
-DisasContext dc;
+DisasContext dc = { };
>>>
>>> We seemed to
Richard Henderson writes:
> Update to include checks against HCR_EL2.TID2.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Alex Bennée
> ---
> target/arm/helper.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/target/arm/helper.c b/ta
On 04/12/19 16:47, Eduardo Habkost wrote:
> On Wed, Dec 04, 2019 at 04:34:45PM +0100, Paolo Bonzini wrote:
>> On 04/12/19 16:07, Catherine Ho wrote:
Ok, so the problem is that some MSR didn't exist in that version. Which
>>> I thought in my platform, the only MSR didn't exist is MSR_IA32_VMX_
On 12/3/19 3:29 AM, Richard Henderson wrote:
Define via macro expansion, so that renumbering of the base ARMMMUIdx
symbols is automatically reflexed in the bit definitions.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 39 +++
1 file changed, 23
On Monday, December 2, 2019, Niek Linnenbank
wrote:
> The Allwinner H3 System on Chip contains multiple USB 2.0 bus
> connections which provide software access using the Enhanced
> Host Controller Interface (EHCI) and Open Host Controller
> Interface (OHCI) interfaces. This commit adds support fo
On 12/4/19 4:46 PM, Thomas Huth wrote:
Test 079 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, which is apparently alread
Richard Henderson writes:
> On 12/4/19 3:43 AM, Alex Bennée wrote:
>>> void gen_intermediate_code(CPUState *cpu, TranslationBlock *tb, int
>>> max_insns)
>>> {
>>> -DisasContext dc;
>>> +DisasContext dc = { };
>>
>> We seemed to have dropped an initialise here which seems unrelated
On Wed, Dec 04, 2019 at 04:34:45PM +0100, Paolo Bonzini wrote:
> On 04/12/19 16:07, Catherine Ho wrote:
> >> Ok, so the problem is that some MSR didn't exist in that version. Which
> > I thought in my platform, the only MSR didn't exist is MSR_IA32_VMX_BASIC
> > (0x480). If I remove this kvm_msr_e
On 12/4/19 4:46 PM, Thomas Huth wrote:
Test 060 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. The repair process
in test 060 creates a file of 64 GiB, so test firs
On 12/4/19 4:46 PM, Thomas Huth wrote:
Some tests create huge (but sparse) files, and to be able to run those
tests in certain limited environments (like CI containers), we have to
check for the possibility to create such files first. Thus let's introduce
a common function to check for large file
From: Alex Bennée
Our docker infrastructure isn't quite as multiarch as we would wish so
let's allow the user to disable it if they want. This will allow us to
use still run check-tcg on non-x86 CI setups.
Signed-off-by: Alex Bennée
Reviewed-by: Stefan Weil
Signed-off-by: Thomas Huth
---
con
test-util-filemonitor fails in restricted non-x86 Travis containers
since they apparently blacklisted some required system calls there.
Let's simply skip the test if we detect such an environment.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
Signed-off-by: Thomas Huth
---
tests
Test 060 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. The repair process
in test 060 creates a file of 64 GiB, so test first whether such large
files are possible a
1 - 100 of 242 matches
Mail list logo
