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
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 was able to run (e.g. the BIOS).
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 standard
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 4), then
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
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 than one case that
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 common
case,
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 clear.
BTW,
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 (forwards or
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 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 eight are
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 we do
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 what we do
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 this
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, more
on
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 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
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
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,
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 it
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;
s-irq_base = 0;
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
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 cascade,
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 in
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 patch this
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
Avi Kivity a...@redhat.com 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 @@ static
On 2012-09-03 17:42, Juan Quintela wrote:
Avi Kivity a...@redhat.com 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
+++
On 09/03/2012 06:42 PM, Juan Quintela wrote:
Avi Kivity a...@redhat.com 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
+++
On 2012-09-03 17:52, Avi Kivity wrote:
On 09/03/2012 06:42 PM, Juan Quintela wrote:
Avi Kivity a...@redhat.com 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
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 a...@redhat.com 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
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 a...@redhat.com wrote:
On 09/03/2012 11:40 AM, Andreas Färber wrote:
Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
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, so my
condition
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?
Then you
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 explain why? I saw that icw3 is
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 BIOS).
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 bios has not run yet?
Then you
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. the BIOS).
Suppose the
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 operation.
The point
39 matches
Mail list logo
