On Tue, 13 Oct 2020 at 21:37, Mihai Carabas wrote:
> Does anyone know if there is any progress with pvpanic patches that
> brings in mmio support [1]?
I don't think so. If I recall correctly there was quite a lot
of discussion on at least one version of that patchset, and it
was never clear to me
Hello,
Does anyone know if there is any progress with pvpanic patches that
brings in mmio support [1]? I see no activity since late 2018, but I do
see support added to the kernel (also asking myself how this was tested):
46f934c misc/pvpanic: add support to get pvpanic device info FDT
b1d9d6c
Hi Peng,
On 12/12/18 2:54 AM, peng.h...@zte.com.cn wrote:
>>> v11 --> v12
>>> realize pvpanic as a pci device and use the mmio of pci device.
>>
>> Do you have a pointer to the kernel patches?
>>
>> Thanks,
>>> drew
>>
> I'm still sorting out the code for the kernel part, and I haven't submit
>> v11 --> v12
>> realize pvpanic as a pci device and use the mmio of pci device.
>
>Do you have a pointer to the kernel patches?
>
>Thanks,
>>drew
>
I'm still sorting out the code for the kernel part, and I haven't submitted a
patch yet.
On Thu, Dec 06, 2018 at 07:25:55PM +0800, Peng Hao wrote:
> The first patches are simple cleanups:
> - patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
>it once for the x86/arm/aarch64 archs,
> - patch 2 simply renames ISA fields/definitions to gener
>v10 --> v11
>change configure interface in virt machine configure parameters.
>
>v11 --> v12
>realize pvpanic as a pci device and use the mmio of pci device.
>
>Philippe Mathieu-Daudé (2):
>hw/misc/pvpanic: Build the pvpanic device in $(common-obj)
>hw/misc/pvpanic: Cosmetic renaming
>
>Peng Hao (
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in
>On Wed, 5 Dec 2018 at 00:28, wrote:
>>
>> >I'm afraid I don't understand. If it's a PCI device then
>> >it does not need to be listed in the device tree or the
>> >ACPI tables at all, because it is probeable by the guest.
>> >This also significantly simplifies the changes needed in QEMU.
>> >
>>
On Wed, 5 Dec 2018 at 00:28, wrote:
>
> >I'm afraid I don't understand. If it's a PCI device then
> >it does not need to be listed in the device tree or the
> >ACPI tables at all, because it is probeable by the guest.
> >This also significantly simplifies the changes needed in QEMU.
> >
>
> It is
>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
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
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 to
> put the device into, plus extra on both kernel and QEMU side
> fo
On Tue, Dec 04, 2018 at 12:59:51PM +, Peter Maydell wrote:
> On Tue, 4 Dec 2018 at 12:47, Daniel P. Berrangé wrote:
> > After it had merged there were some changes and the question of turning
> > it into a PCI device was raised. Paolo was concerned that the guest OS
> > is in an unknown state
On Tue, 4 Dec 2018 at 13:30, Paolo Bonzini wrote:
>
> On 04/12/18 13:59, Peter Maydell wrote:
> > ...and if we'd done it that way in the first place for x86 then
> > we wouldn't be having to do anything at all now for Arm.
> > That suggests to me that we should do it that way now, and then we
> >
On 04/12/18 13:59, Peter Maydell wrote:
> On Tue, 4 Dec 2018 at 12:47, Daniel P. Berrangé wrote:
>> After it had merged there were some changes and the question of turning
>> it into a PCI device was raised. Paolo was concerned that the guest OS
>> is in an unknown state (arbitrary locks held, dat
On Tue, 4 Dec 2018 at 12:47, Daniel P. Berrangé wrote:
> After it had merged there were some changes and the question of turning
> it into a PCI device was raised. Paolo was concerned that the guest OS
> is in an unknown state (arbitrary locks held, data structures corrupt,
> etc) when panic is fi
On Mon, Dec 03, 2018 at 06:50:03PM +, Peter Maydell wrote:
> On Mon, 3 Dec 2018 at 11:04, Peng Hao wrote:
> >
> > The first patches are simple cleanups:
> > - patch 1 move the pvpanic device with the 'ocmmon objects' so we
> > compile
> >it once for the x86/arm/aarch64 ar
On Tue, 4 Dec 2018 at 12:05, Andrew Jones wrote:
> To muddy the waters a bit more, while I'm not opposed to this device
> being a PCI device, there is a chance that someone will still want a
> platform-mmio version as well. I'm not sure how everything will
> eventually fall into place, but I've se
On Tue, Dec 04, 2018 at 09:40:07AM +, Peter Maydell wrote:
> 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 s
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
> expl
>On Mon, 3 Dec 2018 at 11:04, Peng Hao wrote:
>>
>> The first patches are simple cleanups:
>> - patch 1 move the pvpanic device with the 'ocmmon objects' so we
>> compile
>>it once for the x86/arm/aarch64 archs,
>> - patch 2 simply renames ISA fields/definitions to gener
On Mon, 3 Dec 2018 at 11:04, Peng Hao wrote:
>
> The first patches are simple cleanups:
> - patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
>it once for the x86/arm/aarch64 archs,
> - patch 2 simply renames ISA fields/definitions to generic ones.
>
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in
pvpanic mmio support
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-quick@centos7 SHOW_ENV=1 J=8
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
3159b16 pvpanic : update pvpanic document
043c070 hw/misc/pvpani
mmio support
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=8
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
3159b16 pvpanic : update pvpanic document
043c070 hw/misc/pvpani
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in
Hi,
This series failed 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.
Type: series
Subject: [Qemu-devel] [PATCH V8 00/10] add pvpanic mmio support
Message-id: 1543078821-16636-1-git
Hi,
This series failed 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.
Type: series
Subject: [Qemu-devel] [PATCH V8 00/10] add pvpanic mmio support
Message-id: 1543078821-16636-1-git
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic devic
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in the virt machine in an
uniqu
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in the virt machine in an
uniqu
On Sun, Oct 28, 2018 at 02:07:25AM +0800, Peng Hao wrote:
> The first patches are simple cleanups:
> - patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
> it once for the x86/arm/aarch64 archs,
> - patch 2 simply renames ISA fields/definitions to generic ones.
>
> Then inst
The first patches are simple cleanups:
- patch 1 move the pvpanic device with the 'ocmmon objects' so we compile
it once for the x86/arm/aarch64 archs,
- patch 2 simply renames ISA fields/definitions to generic ones.
Then instead of add/use the MMIO pvpanic device in the virt machine in an
uniqu
34 matches
Mail list logo
