| Message ID | 1450081359-7753-1-git-send-email-den@openvz.org |
|---|---|
| State | New |
| Headers | show |
On Mon, Dec 14, 2015 at 11:22:39AM +0300, Denis V. Lunev wrote: > From: Roman Kagan <rkagan@virtuozzo.com> > > On x86-based systems Linux determines the presence and the type of > floppy drives via a query of a CMOS field. So does SeaBIOS when > populating the return data for int 0x13 function 0x08. > > Windows doesn't; instead, it requests this information from BIOS via int > 0x13/0x08 or through ACPI objects _FDE (Floppy Drive Enumerate) and _FDI > (Floppy Drive Information). On UEFI systems only ACPI-based detection > is supported. > > QEMU used not to provide those objects in its DSDT; as a result floppy > drives were invisible to Windows on UEFI/OVMF. > > This patch implements those objects in ASL, making the ACPI interpreter > query the CMOS field and populate the objects. The data values used for > _FDI (which, per ACPI spec, is supposed to be equivalent to BIOS int > 0x13/0x08) are taken from SeaBIOS. > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > Signed-off-by: Denis V. Lunev <den@openvz.org> > CC: Michael S. Tsirkin <mst@redhat.com> > CC: Igor Mammedov <imammedo@redhat.com> > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Eduardo Habkost <ehabkost@redhat.com> This is not a regression, so I'm inclined not to merge this for 2.5. Pls correct me if I'm wrong. > --- > hw/i386/acpi-dsdt-isa.dsl | 109 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 109 insertions(+) > > diff --git a/hw/i386/acpi-dsdt-isa.dsl b/hw/i386/acpi-dsdt-isa.dsl > index 89caa16..8b03e2b 100644 > --- a/hw/i386/acpi-dsdt-isa.dsl > +++ b/hw/i386/acpi-dsdt-isa.dsl > @@ -23,6 +23,8 @@ Scope(\_SB.PCI0.ISA) { > IRQNoFlags() { 8 } > IO(Decode16, 0x0072, 0x0072, 0x02, 0x06) > }) > + > + OperationRegion(CMS0, SystemCMOS, Zero, 0x40) > } > > Device(KBD) { > @@ -63,6 +65,113 @@ Scope(\_SB.PCI0.ISA) { > IRQNoFlags() { 6 } > DMA(Compatibility, NotBusMaster, Transfer8) { 2 } > }) > + > + Field(^RTC.CMS0, ByteAcc, NoLock, Preserve) { > + Offset(0x10), > + FDTS, 8 > + } > + > + Method(FDTY, 1, NotSerialized) { > + If (LEqual(Arg0, 0x00)) { > + Return (And(ShiftRight(FDTS, 0x04), 0x0F)) > + } ElseIf (LEqual(Arg0, 0x01)) { > + Return (And(FDTS, 0x0F)) > + } Else { > + Return (0x00) > + } > + } > + > + Method(_FDE, 0, NotSerialized) { > + Store(Buffer(0x14) {}, Local0) > + CreateDWordField(Local0, 0x00, FDAE) > + CreateDWordField(Local0, 0x04, FDBE) > + CreateDWordField(Local0, 0x10, TAPE) > + > + If (LNotEqual(FDTY(0x00), 0)) { > + Store(0x01, FDAE) > + } > + If (LNotEqual(FDTY(0x01), 0)) { > + Store(0x01, FDBE) > + } > + Store(0x02, TAPE) > + > + Return (Local0) > + } > + > + Method(FSTA, 1, NotSerialized) { > + If (LEqual(FDTY(Arg0), 0x00)) { > + Return (0x00) > + } Else { > + Return (0x0F) > + } > + } > + > + Method(XFDI, 1, NotSerialized) { > + Store(FDTY(Arg0), Local0) > + > + Store(Package (0x10) { > + 0x00, // Drive Number > + 0x00, // Device Type > + 0x00, // Maximum Cylinder Number > + 0x00, // Maximum Sector Number > + 0x00, // Maximum Head Number > + /* SeaBIOS uses the below values regardless of the drive > + * type, so shall we */ > + 0xAF, // disk_specify_1 > + 0x02, // disk_specify_2 > + 0x25, // disk_motor_wait > + 0x02, // disk_sector_siz > + 0x12, // disk_eot > + 0x1B, // disk_rw_gap > + 0xFF, // disk_dtl > + 0x6C, // disk_formt_gap > + 0xF6, // disk_fill > + 0x0F, // disk_head_sttl > + 0x08, // disk_motor_strt > + }, Local1) > + > + Store(Arg0, Index(Local1, 0x00)) > + Store(Local0, Index(Local1, 0x01)) > + > + If (LEqual(Local0, 4)) { > + /* 1.44 Mb 3"5 drive */ > + Store(0x4F, Index(Local1, 0x02)) > + Store(0x12, Index(Local1, 0x03)) > + Store(0x01, Index(Local1, 0x04)) > + } ElseIf (LEqual(Local0, 5)) { > + /* 2.88 Mb 3"5 drive */ > + Store(0x4F, Index(Local1, 0x02)) > + Store(0x24, Index(Local1, 0x03)) > + Store(0x01, Index(Local1, 0x04)) > + } ElseIf (LEqual(Local0, 2)) { > + /* 1.2 Mb 5"5 drive */ > + Store(0x4F, Index(Local1, 0x02)) > + Store(0x0F, Index(Local1, 0x03)) > + Store(0x01, Index(Local1, 0x04)) > + } > + > + Return (Local1) > + } > + > + Device(FLPA) { > + Name(_ADR, 0x00) > + Method(_STA, 0, NotSerialized) { > + Return (FSTA(_ADR)) > + } > + Method(_FDI, 0, NotSerialized) { > + Return (XFDI(_ADR)) > + } > + } > + > + Device(FLPB) { > + Name(_ADR, 0x01) > + Method(_STA, 0, NotSerialized) { > + Return (FSTA(_ADR)) > + } > + Method(_FDI, 0, NotSerialized) { > + Return (XFDI(_ADR)) > + } > + } > } > > Device(LPT) { > -- > 2.1.4
On 12/14/2015 12:21 PM, Michael S. Tsirkin wrote: > On Mon, Dec 14, 2015 at 11:22:39AM +0300, Denis V. Lunev wrote: >> From: Roman Kagan <rkagan@virtuozzo.com> >> >> On x86-based systems Linux determines the presence and the type of >> floppy drives via a query of a CMOS field. So does SeaBIOS when >> populating the return data for int 0x13 function 0x08. >> >> Windows doesn't; instead, it requests this information from BIOS via int >> 0x13/0x08 or through ACPI objects _FDE (Floppy Drive Enumerate) and _FDI >> (Floppy Drive Information). On UEFI systems only ACPI-based detection >> is supported. >> >> QEMU used not to provide those objects in its DSDT; as a result floppy >> drives were invisible to Windows on UEFI/OVMF. >> >> This patch implements those objects in ASL, making the ACPI interpreter >> query the CMOS field and populate the objects. The data values used for >> _FDI (which, per ACPI spec, is supposed to be equivalent to BIOS int >> 0x13/0x08) are taken from SeaBIOS. >> >> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> >> Signed-off-by: Denis V. Lunev <den@openvz.org> >> CC: Michael S. Tsirkin <mst@redhat.com> >> CC: Igor Mammedov <imammedo@redhat.com> >> CC: Paolo Bonzini <pbonzini@redhat.com> >> CC: Richard Henderson <rth@twiddle.net> >> CC: Eduardo Habkost <ehabkost@redhat.com> > This is not a regression, so I'm inclined not to merge this for 2.5. > Pls correct me if I'm wrong. > this was a question actually. Yes, this is not a regression but user observable bug. The floppy is not available in Windows UEFI guests and it is not that easy to get VirtIO drivers in this case installed especially for root disk. Den
On 14/12/2015 10:26, Denis V. Lunev wrote: >> > > this was a question actually. > > Yes, this is not a regression but user observable bug. The floppy > is not available in Windows UEFI guests and it is not that easy > to get VirtIO drivers in this case installed especially for root > disk. Isn't a CD enough for everything except Windows XP (EOLed) and 2003 (not supporting UEFI anyway)? Paolo
On 12/14/2015 12:28 PM, Paolo Bonzini wrote: > > On 14/12/2015 10:26, Denis V. Lunev wrote: >> this was a question actually. >> >> Yes, this is not a regression but user observable bug. The floppy >> is not available in Windows UEFI guests and it is not that easy >> to get VirtIO drivers in this case installed especially for root >> disk. > Isn't a CD enough for everything except Windows XP (EOLed) and 2003 (not > supporting UEFI anyway)? > > Paolo The problem comes from unattended installation. As far as we have tried unattended answers file should come on USB flash or on floppy. In the other case the ISO with Windows distro should be modified. This option we can not afford as we do not control ISO's on the client side :( Den
On 14/12/2015 10:41, Denis V. Lunev wrote: > The problem comes from unattended installation. As far as we > have tried unattended answers file should come on USB flash > or on floppy. Yes, the answers file cannot use an ISO indeed. But as you said it can be USB mass storage. In any case, even if this is a bug that we want to add to 2.5.1, it's definitely too late for 2.5---at any time after soft freeze. Paolo > In the other case the ISO with Windows distro should be > modified. This option we can not afford as we do not control > ISO's on the client side :(
On 12/14/2015 12:44 PM, Paolo Bonzini wrote: > > On 14/12/2015 10:41, Denis V. Lunev wrote: >> The problem comes from unattended installation. As far as we >> have tried unattended answers file should come on USB flash >> or on floppy. > Yes, the answers file cannot use an ISO indeed. But as you said it can > be USB mass storage. > > In any case, even if this is a bug that we want to add to 2.5.1, it's > definitely too late for 2.5---at any time after soft freeze. ok. 2.5.1 would be really great. Thank you for a prompt reply. Though I have a question about the freeze policy as other people still accepting user-visible bugfixes after a soft freeze. By the way, any opinion about the patch itself? :) Den
On 14/12/2015 10:49, Denis V. Lunev wrote: >> >> In any case, even if this is a bug that we want to add to 2.5.1, it's >> definitely too late for 2.5---at any time after soft freeze. > ok. 2.5.1 would be really great. Thank you for a prompt reply. > > Though I have a question about the freeze policy as > other people still accepting user-visible bugfixes > after a soft freeze. Of course things are up to the individual maintainer but, in general, I think that guest-visible changes should be vetted very carefully after soft freeze. It depends on the effect of the change. Changing ACPI tables is quite more far reaching than, say, fixing an infinite loop in a device model (which has never been triggered so far, or we would have had a bug reported). Paolo
On Mon, Dec 14, 2015 at 12:26:17PM +0300, Denis V. Lunev wrote: > On 12/14/2015 12:21 PM, Michael S. Tsirkin wrote: > >On Mon, Dec 14, 2015 at 11:22:39AM +0300, Denis V. Lunev wrote: > >>From: Roman Kagan <rkagan@virtuozzo.com> > >> > >>On x86-based systems Linux determines the presence and the type of > >>floppy drives via a query of a CMOS field. So does SeaBIOS when > >>populating the return data for int 0x13 function 0x08. > >> > >>Windows doesn't; instead, it requests this information from BIOS via int > >>0x13/0x08 or through ACPI objects _FDE (Floppy Drive Enumerate) and _FDI > >>(Floppy Drive Information). On UEFI systems only ACPI-based detection > >>is supported. > >> > >>QEMU used not to provide those objects in its DSDT; as a result floppy > >>drives were invisible to Windows on UEFI/OVMF. > >> > >>This patch implements those objects in ASL, making the ACPI interpreter > >>query the CMOS field and populate the objects. The data values used for > >>_FDI (which, per ACPI spec, is supposed to be equivalent to BIOS int > >>0x13/0x08) are taken from SeaBIOS. > >> > >>Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > >>Signed-off-by: Denis V. Lunev <den@openvz.org> > >>CC: Michael S. Tsirkin <mst@redhat.com> > >>CC: Igor Mammedov <imammedo@redhat.com> > >>CC: Paolo Bonzini <pbonzini@redhat.com> > >>CC: Richard Henderson <rth@twiddle.net> > >>CC: Eduardo Habkost <ehabkost@redhat.com> > >This is not a regression, so I'm inclined not to merge this for 2.5. > >Pls correct me if I'm wrong. > > > > this was a question actually. > > Yes, this is not a regression but user observable bug. The floppy > is not available in Windows UEFI guests and it is not that easy > to get VirtIO drivers in this case installed especially for root > disk. > > Den So it's an important patch but I don't think it's a showstopper for 2.5, and this is too risky to merge without doing another rc. This can go into 2.5.1 perhaps.
On Mon, 14 Dec 2015 11:22:39 +0300 "Denis V. Lunev" <den@openvz.org> wrote: > From: Roman Kagan <rkagan@virtuozzo.com> > > On x86-based systems Linux determines the presence and the type of > floppy drives via a query of a CMOS field. So does SeaBIOS when > populating the return data for int 0x13 function 0x08. > > Windows doesn't; instead, it requests this information from BIOS via > int 0x13/0x08 or through ACPI objects _FDE (Floppy Drive Enumerate) > and _FDI (Floppy Drive Information). On UEFI systems only ACPI-based > detection is supported. > > QEMU used not to provide those objects in its DSDT; as a result floppy > drives were invisible to Windows on UEFI/OVMF. > > This patch implements those objects in ASL, making the ACPI > interpreter query the CMOS field and populate the objects. The data > values used for _FDI (which, per ACPI spec, is supposed to be > equivalent to BIOS int 0x13/0x08) are taken from SeaBIOS. We are in process of removing static DSDT (ASL template) and replacing it with dynamically generated one. So please do not add new ASL to it, instead of it please redo patch using AML API and it would be better if you do it on top of following series: "[PATCH 00/74] pc: acpi: convert DSDT to AML API and drop ASL templates support" http://qemu.patchew.org/series/%3C1449704528-289297-1-git-send-email-imammedo@redhat.com%3E to avoid touching ASL code and avoid conflicts with API changes Patch also could be simpler if you generate _FDE,_FDI dynamically instead of trying to detect drive presence from guest side. See below for comments. > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > Signed-off-by: Denis V. Lunev <den@openvz.org> > CC: Michael S. Tsirkin <mst@redhat.com> > CC: Igor Mammedov <imammedo@redhat.com> > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Richard Henderson <rth@twiddle.net> > CC: Eduardo Habkost <ehabkost@redhat.com> > --- > hw/i386/acpi-dsdt-isa.dsl | 109 > ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 109 > insertions(+) > > diff --git a/hw/i386/acpi-dsdt-isa.dsl b/hw/i386/acpi-dsdt-isa.dsl > index 89caa16..8b03e2b 100644 > --- a/hw/i386/acpi-dsdt-isa.dsl > +++ b/hw/i386/acpi-dsdt-isa.dsl > @@ -23,6 +23,8 @@ Scope(\_SB.PCI0.ISA) { > IRQNoFlags() { 8 } > IO(Decode16, 0x0072, 0x0072, 0x02, 0x06) > }) > + > + OperationRegion(CMS0, SystemCMOS, Zero, 0x40) > } > > Device(KBD) { > @@ -63,6 +65,113 @@ Scope(\_SB.PCI0.ISA) { > IRQNoFlags() { 6 } > DMA(Compatibility, NotBusMaster, Transfer8) { 2 } > }) > + > + Field(^RTC.CMS0, ByteAcc, NoLock, Preserve) { > + Offset(0x10), > + FDTS, 8 > + } > + > + Method(FDTY, 1, NotSerialized) { > + If (LEqual(Arg0, 0x00)) { > + Return (And(ShiftRight(FDTS, 0x04), 0x0F)) > + } ElseIf (LEqual(Arg0, 0x01)) { > + Return (And(FDTS, 0x0F)) > + } Else { > + Return (0x00) > + } > + } > + Assuming you generate AML dynamically, you can drop above hunks altogether since it's generated by QEMU and you can detect floppy drive presence when building static _FDE. > + Method(_FDE, 0, NotSerialized) { > + Store(Buffer(0x14) {}, Local0) > + CreateDWordField(Local0, 0x00, FDAE) > + CreateDWordField(Local0, 0x04, FDBE) > + CreateDWordField(Local0, 0x10, TAPE) > + > + If (LNotEqual(FDTY(0x00), 0)) { > + Store(0x01, FDAE) > + } > + If (LNotEqual(FDTY(0x01), 0)) { > + Store(0x01, FDBE) > + } > + Store(0x02, TAPE) > + > + Return (Local0) > + } replace above function with: uint32_t fde_buf = { fda_present, fdb_present, 0, 0, 0x2}; aml_name_decl("_FDE", aml_buffer(0x14, fde_buf)); > + > + Method(FSTA, 1, NotSerialized) { > + If (LEqual(FDTY(Arg0), 0x00)) { > + Return (0x00) > + } Else { > + Return (0x0F) > + } > + } Drop above, it's not needed, since QEMU does all detection > + > + Method(XFDI, 1, NotSerialized) { > + Store(FDTY(Arg0), Local0) > + > + Store(Package (0x10) { > + 0x00, // Drive Number > + 0x00, // Device Type > + 0x00, // Maximum Cylinder Number > + 0x00, // Maximum Sector Number > + 0x00, // Maximum Head Number > + /* SeaBIOS uses the below values regardless of > the drive > + * type, so shall we */ > + 0xAF, // disk_specify_1 > + 0x02, // disk_specify_2 > + 0x25, // disk_motor_wait > + 0x02, // disk_sector_siz > + 0x12, // disk_eot > + 0x1B, // disk_rw_gap > + 0xFF, // disk_dtl > + 0x6C, // disk_formt_gap > + 0xF6, // disk_fill > + 0x0F, // disk_head_sttl > + 0x08, // disk_motor_strt > + }, Local1) > + > + Store(Arg0, Index(Local1, 0x00)) > + Store(Local0, Index(Local1, 0x01)) > + > + If (LEqual(Local0, 4)) { > + /* 1.44 Mb 3"5 drive */ > + Store(0x4F, Index(Local1, 0x02)) > + Store(0x12, Index(Local1, 0x03)) > + Store(0x01, Index(Local1, 0x04)) > + } ElseIf (LEqual(Local0, 5)) { > + /* 2.88 Mb 3"5 drive */ > + Store(0x4F, Index(Local1, 0x02)) > + Store(0x24, Index(Local1, 0x03)) > + Store(0x01, Index(Local1, 0x04)) > + } ElseIf (LEqual(Local0, 2)) { > + /* 1.2 Mb 5"5 drive */ > + Store(0x4F, Index(Local1, 0x02)) > + Store(0x0F, Index(Local1, 0x03)) > + Store(0x01, Index(Local1, 0x04)) > + } > + > + Return (Local1) do the same as with _FDE, the only difference is that instead of buffer place directly encoded package in it, for example look for comment: /* create S3_ / S4_ / S5_ packages if necessary */ also there is no need to make it function, just put _FDI package for a particular floppy drive right inside of it. > + } > + > + Device(FLPA) { > + Name(_ADR, 0x00) > + Method(_STA, 0, NotSerialized) { > + Return (FSTA(_ADR)) > + } > + Method(_FDI, 0, NotSerialized) { > + Return (XFDI(_ADR)) > + } > + } > + > + Device(FLPB) { > + Name(_ADR, 0x01) > + Method(_STA, 0, NotSerialized) { > + Return (FSTA(_ADR)) > + } > + Method(_FDI, 0, NotSerialized) { > + Return (XFDI(_ADR)) > + } > + } generate a device description only if the corresponding drive is present drop _STA since its assumed that device is present if there isn't _STA object. > } > > Device(LPT) {
On 12/14/2015 06:05 PM, Igor Mammedov wrote: > On Mon, 14 Dec 2015 11:22:39 +0300 > "Denis V. Lunev" <den@openvz.org> wrote: > >> From: Roman Kagan <rkagan@virtuozzo.com> >> >> On x86-based systems Linux determines the presence and the type of >> floppy drives via a query of a CMOS field. So does SeaBIOS when >> populating the return data for int 0x13 function 0x08. >> >> Windows doesn't; instead, it requests this information from BIOS via >> int 0x13/0x08 or through ACPI objects _FDE (Floppy Drive Enumerate) >> and _FDI (Floppy Drive Information). On UEFI systems only ACPI-based >> detection is supported. >> >> QEMU used not to provide those objects in its DSDT; as a result floppy >> drives were invisible to Windows on UEFI/OVMF. >> >> This patch implements those objects in ASL, making the ACPI >> interpreter query the CMOS field and populate the objects. The data >> values used for _FDI (which, per ACPI spec, is supposed to be >> equivalent to BIOS int 0x13/0x08) are taken from SeaBIOS. > We are in process of removing static DSDT (ASL template) and replacing > it with dynamically generated one. > So please do not add new ASL to it, instead of it > please redo patch using AML API and it would be better if you > do it on top of following series: > "[PATCH 00/74] pc: acpi: convert DSDT to AML API and drop ASL > templates support" > http://qemu.patchew.org/series/%3C1449704528-289297-1-git-send-email-imammedo@redhat.com%3E > > to avoid touching ASL code and avoid conflicts with API changes > Patch also could be simpler if you generate _FDE,_FDI > dynamically instead of trying to detect drive presence > from guest side. > See below for comments. Igor, do you have any GIT tree we could be based on :) ? Den
On Mon, 14 Dec 2015 18:11:53 +0300 "Denis V. Lunev" <den@openvz.org> wrote: > On 12/14/2015 06:05 PM, Igor Mammedov wrote: > > On Mon, 14 Dec 2015 11:22:39 +0300 > > "Denis V. Lunev" <den@openvz.org> wrote: > > > >> From: Roman Kagan <rkagan@virtuozzo.com> > >> > >> On x86-based systems Linux determines the presence and the type of > >> floppy drives via a query of a CMOS field. So does SeaBIOS when > >> populating the return data for int 0x13 function 0x08. > >> > >> Windows doesn't; instead, it requests this information from BIOS > >> via int 0x13/0x08 or through ACPI objects _FDE (Floppy Drive > >> Enumerate) and _FDI (Floppy Drive Information). On UEFI systems > >> only ACPI-based detection is supported. > >> > >> QEMU used not to provide those objects in its DSDT; as a result > >> floppy drives were invisible to Windows on UEFI/OVMF. > >> > >> This patch implements those objects in ASL, making the ACPI > >> interpreter query the CMOS field and populate the objects. The > >> data values used for _FDI (which, per ACPI spec, is supposed to be > >> equivalent to BIOS int 0x13/0x08) are taken from SeaBIOS. > > We are in process of removing static DSDT (ASL template) and > > replacing it with dynamically generated one. > > So please do not add new ASL to it, instead of it > > please redo patch using AML API and it would be better if you > > do it on top of following series: > > "[PATCH 00/74] pc: acpi: convert DSDT to AML API and drop ASL > > templates support" > > http://qemu.patchew.org/series/%3C1449704528-289297-1-git-send-email-imammedo@redhat.com%3E > > > > to avoid touching ASL code and avoid conflicts with API changes > > Patch also could be simpler if you generate _FDE,_FDI > > dynamically instead of trying to detect drive presence > > from guest side. > > See below for comments. > Igor, > > do you have any GIT tree we could be based on :) ? > > Den On Thu, 10 Dec 2015 17:44:30 +0100 Igor Mammedov <imammedo@redhat.com> wrote: > forgot to mention > git tree for testing is available at: > > git@github.com:imammedo/qemu.git drop_ASL_support_v1 > or > https://github.com/imammedo/qemu/commits/drop_ASL_support_v1 > > and fixed-up series with fixed comments is at: > > git@github.com:imammedo/qemu.git drop_ASL_support_wip > or > https://github.com/imammedo/qemu/commits/drop_ASL_support_wip if you have in mind 2.5 stable tree for the patch then it would be better to put stuff in SSDT, that way it could be used for stable and later in 2.6 I could clean it up, when merging DSDT with SSDT. Just make sure to put it in some place that avoids conflicts with above series. That way you won't depend on huge ACPI refactoring.
On Mon, Dec 14, 2015 at 04:05:03PM +0100, Igor Mammedov wrote: > On Mon, 14 Dec 2015 11:22:39 +0300 > "Denis V. Lunev" <den@openvz.org> wrote: > > > From: Roman Kagan <rkagan@virtuozzo.com> > > > > On x86-based systems Linux determines the presence and the type of > > floppy drives via a query of a CMOS field. So does SeaBIOS when > > populating the return data for int 0x13 function 0x08. > > > > Windows doesn't; instead, it requests this information from BIOS via > > int 0x13/0x08 or through ACPI objects _FDE (Floppy Drive Enumerate) > > and _FDI (Floppy Drive Information). On UEFI systems only ACPI-based > > detection is supported. > > > > QEMU used not to provide those objects in its DSDT; as a result floppy > > drives were invisible to Windows on UEFI/OVMF. > > > > This patch implements those objects in ASL, making the ACPI > > interpreter query the CMOS field and populate the objects. The data > > values used for _FDI (which, per ACPI spec, is supposed to be > > equivalent to BIOS int 0x13/0x08) are taken from SeaBIOS. > We are in process of removing static DSDT (ASL template) and replacing > it with dynamically generated one. > So please do not add new ASL to it, instead of it > please redo patch using AML API and it would be better if you > do it on top of following series: > "[PATCH 00/74] pc: acpi: convert DSDT to AML API and drop ASL > templates support" > http://qemu.patchew.org/series/%3C1449704528-289297-1-git-send-email-imammedo@redhat.com%3E Yes we do know about this effort. However we thought of this patch as a bugfix rather than a new feature so we did it against the current tree, to make it easy both to merge in the master and to backport to the branches so that the distros could pick it up in their packages. Do I get you right that we should better direct this patch to qemu-stable, and cook up a new one on top of your series for master? Roman.
On Mon, 14 Dec 2015 18:38:03 +0300 Roman Kagan <rkagan@virtuozzo.com> wrote: > On Mon, Dec 14, 2015 at 04:05:03PM +0100, Igor Mammedov wrote: > > On Mon, 14 Dec 2015 11:22:39 +0300 > > "Denis V. Lunev" <den@openvz.org> wrote: > > > > > From: Roman Kagan <rkagan@virtuozzo.com> > > > > > > On x86-based systems Linux determines the presence and the type of > > > floppy drives via a query of a CMOS field. So does SeaBIOS when > > > populating the return data for int 0x13 function 0x08. > > > > > > Windows doesn't; instead, it requests this information from BIOS > > > via int 0x13/0x08 or through ACPI objects _FDE (Floppy Drive > > > Enumerate) and _FDI (Floppy Drive Information). On UEFI systems > > > only ACPI-based detection is supported. > > > > > > QEMU used not to provide those objects in its DSDT; as a result > > > floppy drives were invisible to Windows on UEFI/OVMF. > > > > > > This patch implements those objects in ASL, making the ACPI > > > interpreter query the CMOS field and populate the objects. The > > > data values used for _FDI (which, per ACPI spec, is supposed to be > > > equivalent to BIOS int 0x13/0x08) are taken from SeaBIOS. > > We are in process of removing static DSDT (ASL template) and > > replacing it with dynamically generated one. > > So please do not add new ASL to it, instead of it > > please redo patch using AML API and it would be better if you > > do it on top of following series: > > "[PATCH 00/74] pc: acpi: convert DSDT to AML API and drop ASL > > templates support" > > http://qemu.patchew.org/series/%3C1449704528-289297-1-git-send-email-imammedo@redhat.com%3E > > Yes we do know about this effort. However we thought of this patch > as a bugfix rather than a new feature so we did it against the > current tree, to make it easy both to merge in the master and to > backport to the branches so that the distros could pick it up in > their packages. > > Do I get you right that we should better direct this patch to > qemu-stable, and cook up a new one on top of your series for master? You can do just single patch for both trees without dependency on above series, just put new AML into SSDT as described in comments. > > Roman.
diff --git a/hw/i386/acpi-dsdt-isa.dsl b/hw/i386/acpi-dsdt-isa.dsl index 89caa16..8b03e2b 100644 --- a/hw/i386/acpi-dsdt-isa.dsl +++ b/hw/i386/acpi-dsdt-isa.dsl @@ -23,6 +23,8 @@ Scope(\_SB.PCI0.ISA) { IRQNoFlags() { 8 } IO(Decode16, 0x0072, 0x0072, 0x02, 0x06) }) + + OperationRegion(CMS0, SystemCMOS, Zero, 0x40) } Device(KBD) { @@ -63,6 +65,113 @@ Scope(\_SB.PCI0.ISA) { IRQNoFlags() { 6 } DMA(Compatibility, NotBusMaster, Transfer8) { 2 } }) + + Field(^RTC.CMS0, ByteAcc, NoLock, Preserve) { + Offset(0x10), + FDTS, 8 + } + + Method(FDTY, 1, NotSerialized) { + If (LEqual(Arg0, 0x00)) { + Return (And(ShiftRight(FDTS, 0x04), 0x0F)) + } ElseIf (LEqual(Arg0, 0x01)) { + Return (And(FDTS, 0x0F)) + } Else { + Return (0x00) + } + } + + Method(_FDE, 0, NotSerialized) { + Store(Buffer(0x14) {}, Local0) + CreateDWordField(Local0, 0x00, FDAE) + CreateDWordField(Local0, 0x04, FDBE) + CreateDWordField(Local0, 0x10, TAPE) + + If (LNotEqual(FDTY(0x00), 0)) { + Store(0x01, FDAE) + } + If (LNotEqual(FDTY(0x01), 0)) { + Store(0x01, FDBE) + } + Store(0x02, TAPE) + + Return (Local0) + } + + Method(FSTA, 1, NotSerialized) { + If (LEqual(FDTY(Arg0), 0x00)) { + Return (0x00) + } Else { + Return (0x0F) + } + } + + Method(XFDI, 1, NotSerialized) { + Store(FDTY(Arg0), Local0) + + Store(Package (0x10) { + 0x00, // Drive Number + 0x00, // Device Type + 0x00, // Maximum Cylinder Number + 0x00, // Maximum Sector Number + 0x00, // Maximum Head Number + /* SeaBIOS uses the below values regardless of the drive + * type, so shall we */ + 0xAF, // disk_specify_1 + 0x02, // disk_specify_2 + 0x25, // disk_motor_wait + 0x02, // disk_sector_siz + 0x12, // disk_eot + 0x1B, // disk_rw_gap + 0xFF, // disk_dtl + 0x6C, // disk_formt_gap + 0xF6, // disk_fill + 0x0F, // disk_head_sttl + 0x08, // disk_motor_strt + }, Local1) + + Store(Arg0, Index(Local1, 0x00)) + Store(Local0, Index(Local1, 0x01)) + + If (LEqual(Local0, 4)) { + /* 1.44 Mb 3"5 drive */ + Store(0x4F, Index(Local1, 0x02)) + Store(0x12, Index(Local1, 0x03)) + Store(0x01, Index(Local1, 0x04)) + } ElseIf (LEqual(Local0, 5)) { + /* 2.88 Mb 3"5 drive */ + Store(0x4F, Index(Local1, 0x02)) + Store(0x24, Index(Local1, 0x03)) + Store(0x01, Index(Local1, 0x04)) + } ElseIf (LEqual(Local0, 2)) { + /* 1.2 Mb 5"5 drive */ + Store(0x4F, Index(Local1, 0x02)) + Store(0x0F, Index(Local1, 0x03)) + Store(0x01, Index(Local1, 0x04)) + } + + Return (Local1) + } + + Device(FLPA) { + Name(_ADR, 0x00) + Method(_STA, 0, NotSerialized) { + Return (FSTA(_ADR)) + } + Method(_FDI, 0, NotSerialized) { + Return (XFDI(_ADR)) + } + } + + Device(FLPB) { + Name(_ADR, 0x01) + Method(_STA, 0, NotSerialized) { + Return (FSTA(_ADR)) + } + Method(_FDI, 0, NotSerialized) { + Return (XFDI(_ADR)) + } + } } Device(LPT) {