>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
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
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
>
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,
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
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
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
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
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 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
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
14 matches
Mail list logo
