On 2012-09-05 06:33, Matthew Ogilvie wrote:
> According to later discussion, the main issue is actually the input
> IRQ behavior on a high to low transition; hence the following fixes
> both the test program and the Microport UNIX problem:
>
> diff --git a/hw/i8259.c b/hw/i8259.c
> index 6587666..
On Tue, Sep 04, 2012 at 04:42:35PM +0200, Paolo Bonzini wrote:
> Il 04/09/2012 16:29, Maciej W. Rozycki ha scritto:
> > So first of all, the *output* of the 8259A is always edge triggered,
> > regardless of whether it's the master or one of the slaves (only one slave
> > is used in the PC/AT arc
On Tue, 4 Sep 2012, Jan Kiszka wrote:
> >> What I'm trying to understand and translate from the description is
> >> rather "note that for inputs a high-to-low transition cancels the
> >> interrupt as in the level-triggered mode." This is surely not what we do
> >> right now. OTOH, I'm afraid that
On Mon, 3 Sep 2012, Jan Kiszka wrote:
> > - Qemu output (without this patch):
> > elcr=0c00 cmdRead ummask mask sti irq15 unmask DONE
> >
> > But on real hardware, the master seems to treat IRQ2 as level triggered,
That is not universally true, however in reality it does not matter, m
On Tue, 4 Sep 2012, Jan Kiszka wrote:
> What I'm trying to understand and translate from the description is
> rather "note that for inputs a high-to-low transition cancels the
> interrupt as in the level-triggered mode." This is surely not what we do
> right now. OTOH, I'm afraid that switching to
On 2012-09-04 20:27, Maciej W. Rozycki wrote:
> On Tue, 4 Sep 2012, Jan Kiszka wrote:
>
What I'm trying to understand and translate from the description is
rather "note that for inputs a high-to-low transition cancels the
interrupt as in the level-triggered mode." This is surely not
On 2012-09-04 19:41, Maciej W. Rozycki wrote:
> On Tue, 4 Sep 2012, Jan Kiszka wrote:
>
>> What I'm trying to understand and translate from the description is
>> rather "note that for inputs a high-to-low transition cancels the
>> interrupt as in the level-triggered mode." This is surely not what
On 2012-09-04 16:42, Paolo Bonzini wrote:
> Il 04/09/2012 16:29, Maciej W. Rozycki ha scritto:
>> So first of all, the *output* of the 8259A is always edge triggered,
>> regardless of whether it's the master or one of the slaves (only one slave
>> is used in the PC/AT architecture, but up to eig
Il 04/09/2012 16:29, Maciej W. Rozycki ha scritto:
> So first of all, the *output* of the 8259A is always edge triggered,
> regardless of whether it's the master or one of the slaves (only one slave
> is used in the PC/AT architecture, but up to eight are supported; the
> PC/XT had none).
I
On 09/04/2012 01:06 PM, Paolo Bonzini wrote:
> Il 04/09/2012 11:51, Jan Kiszka ha scritto:
>>> >
>>> > I don't mean to say we shouldn't care about them, but there are likely
>>> > to be a lot more users doing backwards migration than users running
>>> > those guests, let alone migrating them (forw
Il 04/09/2012 11:51, Jan Kiszka ha scritto:
>> >
>> > I don't mean to say we shouldn't care about them, but there are likely
>> > to be a lot more users doing backwards migration than users running
>> > those guests, let alone migrating them (forwards or backwards). The
>> > pragmatic choice is c
On 2012-09-04 11:37, Avi Kivity wrote:
> On 09/04/2012 12:29 PM, BALATON Zoltan wrote:
>> On Tue, 4 Sep 2012, Avi Kivity wrote:
>>> On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
Il 04/09/2012 10:16, Avi Kivity ha scritto:
>>> But the point of subsections is to succeed migration in the commo
On 09/04/2012 12:29 PM, BALATON Zoltan wrote:
> On Tue, 4 Sep 2012, Avi Kivity wrote:
>> On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
>>> Il 04/09/2012 10:16, Avi Kivity ha scritto:
>> But the point of subsections is to succeed migration in the common
>> case,
>> assuming there is more
On Tue, 4 Sep 2012, Avi Kivity wrote:
On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
Il 04/09/2012 10:16, Avi Kivity ha scritto:
But the point of subsections is to succeed migration in the common case,
assuming there is more than one case that doesn't affect guest operation.
According to the pat
On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
> Il 04/09/2012 10:16, Avi Kivity ha scritto:
>>> > But the point of subsections is to succeed migration in the common case,
>>> > assuming there is more than one case that doesn't affect guest operation.
>> According to the patch, if icw3 == 4 && !(eclr
Il 04/09/2012 10:16, Avi Kivity ha scritto:
>> > But the point of subsections is to succeed migration in the common case,
>> > assuming there is more than one case that doesn't affect guest operation.
> According to the patch, if icw3 == 4 && !(eclr & 4), then behaviour will
> change. With the sta
On 09/03/2012 07:33 PM, Paolo Bonzini wrote:
> Il 03/09/2012 18:30, Avi Kivity ha scritto:
>> The values above are what every user of the PIC cascaded on our targets
>> >>> > must program to use them. So We will find them in the state once
>> >>> > any
>> >>> > relevant guest code
Il 03/09/2012 18:40, Jan Kiszka ha scritto:
>>> >> And the migration fails. Needlessly, since icw3 == 0 doesn't affect
>>> >> guest operation.
>> >
>> > But the point of subsections is to succeed migration in the common case,
>> > assuming there is more than one case that doesn't affect guest ope
On 2012-09-03 18:33, Paolo Bonzini wrote:
> Il 03/09/2012 18:30, Avi Kivity ha scritto:
>> The values above are what every user of the PIC cascaded on our targets
>> must program to use them. So We will find them in the state once any
>> relevant guest code was able to run (e.g.
Il 03/09/2012 18:30, Avi Kivity ha scritto:
> The values above are what every user of the PIC cascaded on our targets
> >>> > must program to use them. So We will find them in the state once any
> >>> > relevant guest code was able to run (e.g. the BIOS).
> >>> >
>>> >> Suppose the
On 09/03/2012 07:23 PM, Paolo Bonzini wrote:
> Il 03/09/2012 18:15, Avi Kivity ha scritto:
>>> > The values above are what every user of the PIC cascaded on our targets
>>> > must program to use them. So We will find them in the state once any
>>> > relevant guest code was able to run (e.g. the BIO
On 2012-09-03 18:15, Avi Kivity wrote:
> On 09/03/2012 07:02 PM, Jan Kiszka wrote:
>
> Looks like the optimal condition is ((s->icw3 & ~s->eclr) != 0) (i.e.
> bit set in icw3 but clear in eclr).
The standard PC values are optimal: 4 for master, 2 for slave.
>>>
>>> Can you explai
Il 03/09/2012 18:15, Avi Kivity ha scritto:
>> > The values above are what every user of the PIC cascaded on our targets
>> > must program to use them. So We will find them in the state once any
>> > relevant guest code was able to run (e.g. the BIOS).
>> >
> Suppose the bios has not run yet?
The
On 09/03/2012 07:02 PM, Jan Kiszka wrote:
Looks like the optimal condition is ((s->icw3 & ~s->eclr) != 0) (i.e.
bit set in icw3 but clear in eclr).
>>>
>>> The standard PC values are optimal: 4 for master, 2 for slave.
>>
>> Can you explain why? I saw that icw3 is always ORed with eclr
On 2012-09-03 17:57, Avi Kivity wrote:
> On 09/03/2012 06:54 PM, Jan Kiszka wrote:
>> On 2012-09-03 17:52, Avi Kivity wrote:
>>> On 09/03/2012 06:42 PM, Juan Quintela wrote:
Avi Kivity wrote:
> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>> Am 03.09.2012 04:56, schrieb Matthew Ogilv
On 09/03/2012 06:54 PM, Jan Kiszka wrote:
> On 2012-09-03 17:52, Avi Kivity wrote:
>> On 09/03/2012 06:42 PM, Juan Quintela wrote:
>>> Avi Kivity wrote:
On 09/03/2012 11:40 AM, Andreas Färber wrote:
> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
>> diff --git a/hw/i8259_common.c b/hw
On 2012-09-03 17:52, Avi Kivity wrote:
> On 09/03/2012 06:42 PM, Juan Quintela wrote:
>> Avi Kivity wrote:
>>> On 09/03/2012 11:40 AM, Andreas Färber wrote:
Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
> index ab3d98b..dcde5f2 1006
On 09/03/2012 06:42 PM, Juan Quintela wrote:
> Avi Kivity wrote:
>> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>>> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
diff --git a/hw/i8259_common.c b/hw/i8259_common.c
index ab3d98b..dcde5f2 100644
--- a/hw/i8259_common.c
+++ b/hw/
On 2012-09-03 17:42, Juan Quintela wrote:
> Avi Kivity wrote:
>> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>>> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
diff --git a/hw/i8259_common.c b/hw/i8259_common.c
index ab3d98b..dcde5f2 100644
--- a/hw/i8259_common.c
+++ b/hw/i82
Avi Kivity wrote:
> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
>>> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
>>> index ab3d98b..dcde5f2 100644
>>> --- a/hw/i8259_common.c
>>> +++ b/hw/i8259_common.c
>> [...]
>>> @@ -111,6 +112,7 @@ stati
On 09/03/2012 11:40 AM, Andreas Färber wrote:
> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
>> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
>> index ab3d98b..dcde5f2 100644
>> --- a/hw/i8259_common.c
>> +++ b/hw/i8259_common.c
> [...]
>> @@ -111,6 +112,7 @@ static const VMStateDescription v
On 2012-09-03 13:11, Paolo Bonzini wrote:
> Il 03/09/2012 12:34, Jan Kiszka ha scritto:
Why is this a problem? All of them use IRQ2 for a cascade, and initialize
icw3 to 0x4/0x2 (I checked OpenBIOS, rth's palcode for Alpha, and Linux).
>> IRQ2 is already hard-coded in QEMU (we had to pat
Il 03/09/2012 12:34, Jan Kiszka ha scritto:
>> > Why is this a problem? All of them use IRQ2 for a cascade, and initialize
>> > icw3 to 0x4/0x2 (I checked OpenBIOS, rth's palcode for Alpha, and Linux).
> IRQ2 is already hard-coded in QEMU (we had to patch this for our machine
> emulation, but less
On 2012-09-03 11:34, Paolo Bonzini wrote:
> Il 03/09/2012 10:51, Jan Kiszka ha scritto:
>> The only thing that worries me is that we just consider the PC so far
>> while the i8259 is also used on different architectures (PPC, MIPS, Alpha?).
>
> Why is this a problem? All of them use IRQ2 for a ca
Il 03/09/2012 10:51, Jan Kiszka ha scritto:
> The only thing that worries me is that we just consider the PC so far
> while the i8259 is also used on different architectures (PPC, MIPS, Alpha?).
Why is this a problem? All of them use IRQ2 for a cascade, and initialize
icw3 to 0x4/0x2 (I checked O
On 2012-09-03 10:51, Jan Kiszka wrote:
>> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
>> index ab3d98b..dcde5f2 100644
>> --- a/hw/i8259_common.c
>> +++ b/hw/i8259_common.c
>> @@ -33,6 +33,7 @@ void pic_reset_common(PICCommonState *s)
>> s->isr = 0;
>> s->priority_add = 0;
>>
On 2012-09-03 04:56, Matthew Ogilvie wrote:
> Although I haven't found any specs that say so, on real hardware
> I have a test program that shows if you mask off the slave
> interrupt (say IRQ14) in the IMR after it has already been raised,
> the master (IRQ2) gets canceled (that is, IRQ2 acts like
Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
> index ab3d98b..dcde5f2 100644
> --- a/hw/i8259_common.c
> +++ b/hw/i8259_common.c
[...]
> @@ -111,6 +112,7 @@ static const VMStateDescription vmstate_pic_common = {
> VMSTATE_UINT8(isr, PIC
Il 03/09/2012 04:56, Matthew Ogilvie ha scritto:
> Although I haven't found any specs that say so, on real hardware
> I have a test program that shows if you mask off the slave
> interrupt (say IRQ14) in the IMR after it has already been raised,
> the master (IRQ2) gets canceled (that is, IRQ2 acts
Although I haven't found any specs that say so, on real hardware
I have a test program that shows if you mask off the slave
interrupt (say IRQ14) in the IMR after it has already been raised,
the master (IRQ2) gets canceled (that is, IRQ2 acts like it is level
triggered). Without this patch, qemu d
40 matches
Mail list logo
