* x86: Question regarding the reset value of LINT0
@ 2015-04-08 16:40 Nadav Amit
2015-04-08 16:44 ` Jan Kiszka
0 siblings, 1 reply; 17+ messages in thread
From: Nadav Amit @ 2015-04-08 16:40 UTC (permalink / raw)
To: kvm list
Hi,
I would appreciate if someone explains the reason for enabling LINT0 during
APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local
Vector Table” that says all LVT registers are reset to 0x10000.
In kvm_lapic_reset, I see:
apic_set_reg(apic, APIC_LVT0,
SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
Which is actually pretty similar to QEMU’s apic_reset_common:
if (bsp) {
/*
* LINT0 delivery mode on CPU #0 is set to ExtInt at initialization
* time typically by BIOS, so PIC interrupt can be delivered to the
* processor when local APIC is enabled.
*/
s->lvt[APIC_LVT_LINT0] = 0x700;
}
Yet, in both cases, I miss the point - if it is typically done by the BIOS,
why does QEMU or KVM enable it?
BTW: KVM seems to run fine without it, and I think setting it causes me
problems in certain cases.
Thanks,
Nadav
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: x86: Question regarding the reset value of LINT0 2015-04-08 16:40 x86: Question regarding the reset value of LINT0 Nadav Amit @ 2015-04-08 16:44 ` Jan Kiszka 2015-04-08 16:59 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Jan Kiszka @ 2015-04-08 16:44 UTC (permalink / raw) To: Nadav Amit, kvm list On 2015-04-08 18:40, Nadav Amit wrote: > Hi, > > I would appreciate if someone explains the reason for enabling LINT0 during > APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local > Vector Table” that says all LVT registers are reset to 0x10000. > > In kvm_lapic_reset, I see: > > apic_set_reg(apic, APIC_LVT0, > SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); > > Which is actually pretty similar to QEMU’s apic_reset_common: > > if (bsp) { > /* > * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization > * time typically by BIOS, so PIC interrupt can be delivered to the > * processor when local APIC is enabled. > */ > s->lvt[APIC_LVT_LINT0] = 0x700; > } > > Yet, in both cases, I miss the point - if it is typically done by the BIOS, > why does QEMU or KVM enable it? > > BTW: KVM seems to run fine without it, and I think setting it causes me > problems in certain cases. I suspect it has some historic BIOS backgrounds. Already tried to find more information in the git logs of both code bases? Or something that indicates of SeaBIOS or BochsBIOS once didn't do this initialization? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 16:44 ` Jan Kiszka @ 2015-04-08 16:59 ` Nadav Amit 2015-04-08 17:06 ` Jan Kiszka 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-08 16:59 UTC (permalink / raw) To: Jan Kiszka, Avi Kivity; +Cc: kvm list Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 2015-04-08 18:40, Nadav Amit wrote: >> Hi, >> >> I would appreciate if someone explains the reason for enabling LINT0 during >> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >> Vector Table” that says all LVT registers are reset to 0x10000. >> >> In kvm_lapic_reset, I see: >> >> apic_set_reg(apic, APIC_LVT0, >> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >> >> Which is actually pretty similar to QEMU’s apic_reset_common: >> >> if (bsp) { >> /* >> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >> * time typically by BIOS, so PIC interrupt can be delivered to the >> * processor when local APIC is enabled. >> */ >> s->lvt[APIC_LVT_LINT0] = 0x700; >> } >> >> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >> why does QEMU or KVM enable it? >> >> BTW: KVM seems to run fine without it, and I think setting it causes me >> problems in certain cases. > > I suspect it has some historic BIOS backgrounds. Already tried to find > more information in the git logs of both code bases? Or something that > indicates of SeaBIOS or BochsBIOS once didn't do this initialization? Thanks. I found no indication of such thing. QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: Don't route PIC interrupts through the local APIC if the local APIC config says so. By Ari Kivity. Maybe Avi Kivity knows this guy. Regards, Nadav ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 16:59 ` Nadav Amit @ 2015-04-08 17:06 ` Jan Kiszka 2015-04-08 17:40 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Jan Kiszka @ 2015-04-08 17:06 UTC (permalink / raw) To: Nadav Amit, Avi Kivity; +Cc: kvm list On 2015-04-08 18:59, Nadav Amit wrote: > Jan Kiszka <jan.kiszka@siemens.com> wrote: > >> On 2015-04-08 18:40, Nadav Amit wrote: >>> Hi, >>> >>> I would appreciate if someone explains the reason for enabling LINT0 during >>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>> Vector Table” that says all LVT registers are reset to 0x10000. >>> >>> In kvm_lapic_reset, I see: >>> >>> apic_set_reg(apic, APIC_LVT0, >>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>> >>> Which is actually pretty similar to QEMU’s apic_reset_common: >>> >>> if (bsp) { >>> /* >>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>> * time typically by BIOS, so PIC interrupt can be delivered to the >>> * processor when local APIC is enabled. >>> */ >>> s->lvt[APIC_LVT_LINT0] = 0x700; >>> } >>> >>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>> why does QEMU or KVM enable it? >>> >>> BTW: KVM seems to run fine without it, and I think setting it causes me >>> problems in certain cases. >> >> I suspect it has some historic BIOS backgrounds. Already tried to find >> more information in the git logs of both code bases? Or something that >> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? > Thanks. I found no indication of such thing. > > QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: > > Don't route PIC interrupts through the local APIC if the local APIC > config says so. By Ari Kivity. > > Maybe Avi Kivity knows this guy. ths? That should have been Thiemo Seufer (IIRC), but he just committed the code back then (and is no longer with us, sadly). But if that commit went in without any BIOS changes around it, QEMU simply had to do the job of the latter to keep things working. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 17:06 ` Jan Kiszka @ 2015-04-08 17:40 ` Nadav Amit 2015-04-08 17:51 ` Jan Kiszka 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-08 17:40 UTC (permalink / raw) To: Jan Kiszka, Paolo Bonzini; +Cc: Avi Kivity, kvm list Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 2015-04-08 18:59, Nadav Amit wrote: >> Jan Kiszka <jan.kiszka@siemens.com> wrote: >> >>> On 2015-04-08 18:40, Nadav Amit wrote: >>>> Hi, >>>> >>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>> >>>> In kvm_lapic_reset, I see: >>>> >>>> apic_set_reg(apic, APIC_LVT0, >>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>> >>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>> >>>> if (bsp) { >>>> /* >>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>> * processor when local APIC is enabled. >>>> */ >>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>> } >>>> >>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>> why does QEMU or KVM enable it? >>>> >>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>> problems in certain cases. >>> >>> I suspect it has some historic BIOS backgrounds. Already tried to find >>> more information in the git logs of both code bases? Or something that >>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >> Thanks. I found no indication of such thing. >> >> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >> >> Don't route PIC interrupts through the local APIC if the local APIC >> config says so. By Ari Kivity. >> >> Maybe Avi Kivity knows this guy. > > ths? That should have been Thiemo Seufer (IIRC), but he just committed > the code back then (and is no longer with us, sadly). Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke about Avi knowing “Ari”). > But if that commit went in without any BIOS changes around it, QEMU > simply had to do the job of the latter to keep things working. So should I leave it as is? Can I at least disable in KVM during INIT (and leave it as is for RESET)? Thanks, Nadav ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 17:40 ` Nadav Amit @ 2015-04-08 17:51 ` Jan Kiszka 2015-04-08 21:49 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Jan Kiszka @ 2015-04-08 17:51 UTC (permalink / raw) To: Nadav Amit, Paolo Bonzini; +Cc: Avi Kivity, kvm list On 2015-04-08 19:40, Nadav Amit wrote: > Jan Kiszka <jan.kiszka@siemens.com> wrote: > >> On 2015-04-08 18:59, Nadav Amit wrote: >>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> >>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>> Hi, >>>>> >>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>> >>>>> In kvm_lapic_reset, I see: >>>>> >>>>> apic_set_reg(apic, APIC_LVT0, >>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>> >>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>> >>>>> if (bsp) { >>>>> /* >>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>> * processor when local APIC is enabled. >>>>> */ >>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>> } >>>>> >>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>> why does QEMU or KVM enable it? >>>>> >>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>> problems in certain cases. >>>> >>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>> more information in the git logs of both code bases? Or something that >>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>> Thanks. I found no indication of such thing. >>> >>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>> >>> Don't route PIC interrupts through the local APIC if the local APIC >>> config says so. By Ari Kivity. >>> >>> Maybe Avi Kivity knows this guy. >> >> ths? That should have been Thiemo Seufer (IIRC), but he just committed >> the code back then (and is no longer with us, sadly). > Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke > about Avi knowing “Ari”). Ah. No problem. My brain apparently fixed that typo up unnoticed. > >> But if that commit went in without any BIOS changes around it, QEMU >> simply had to do the job of the latter to keep things working. > So should I leave it as is? Can I at least disable in KVM during INIT (and > leave it as is for RESET)? No, I don't think there is a need to leave this inaccurate for QEMU if our included BIOS gets it right. I don't know what the backward bug-compatibility of KVM is, though. Maybe you can identify since when our BIOS is fine so that we can discuss time frames. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 17:51 ` Jan Kiszka @ 2015-04-08 21:49 ` Nadav Amit 2015-04-08 22:11 ` Bandan Das 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-08 21:49 UTC (permalink / raw) To: Jan Kiszka; +Cc: Paolo Bonzini, Avi Kivity, kvm list Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 2015-04-08 19:40, Nadav Amit wrote: >> Jan Kiszka <jan.kiszka@siemens.com> wrote: >> >>> On 2015-04-08 18:59, Nadav Amit wrote: >>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>> >>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>> Hi, >>>>>> >>>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>>> >>>>>> In kvm_lapic_reset, I see: >>>>>> >>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>> >>>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>>> >>>>>> if (bsp) { >>>>>> /* >>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>>> * processor when local APIC is enabled. >>>>>> */ >>>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>>> } >>>>>> >>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>>> why does QEMU or KVM enable it? >>>>>> >>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>>> problems in certain cases. >>>>> >>>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>>> more information in the git logs of both code bases? Or something that >>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>>> Thanks. I found no indication of such thing. >>>> >>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>>> >>>> Don't route PIC interrupts through the local APIC if the local APIC >>>> config says so. By Ari Kivity. >>>> >>>> Maybe Avi Kivity knows this guy. >>> >>> ths? That should have been Thiemo Seufer (IIRC), but he just committed >>> the code back then (and is no longer with us, sadly). >> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke >> about Avi knowing “Ari”). > > Ah. No problem. My brain apparently fixed that typo up unnoticed. > >>> But if that commit went in without any BIOS changes around it, QEMU >>> simply had to do the job of the latter to keep things working. >> So should I leave it as is? Can I at least disable in KVM during INIT (and >> leave it as is for RESET)? > > No, I don't think there is a need to leave this inaccurate for QEMU if > our included BIOS gets it right. I don't know what the backward > bug-compatibility of KVM is, though. Maybe you can identify since when > our BIOS is fine so that we can discuss time frames. I think that it was addressed in commit 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the local APIC of the BSP.”) So it should be included in seabios 0.5.0, which means qemu 0.12 - so we are talking about the end of 2009 or start of 2010. What is the verdict? Nadav ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 21:49 ` Nadav Amit @ 2015-04-08 22:11 ` Bandan Das 2015-04-09 18:21 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Bandan Das @ 2015-04-08 22:11 UTC (permalink / raw) To: Nadav Amit; +Cc: Jan Kiszka, Paolo Bonzini, Avi Kivity, kvm list Nadav Amit <nadav.amit@gmail.com> writes: > Jan Kiszka <jan.kiszka@siemens.com> wrote: > >> On 2015-04-08 19:40, Nadav Amit wrote: >>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> >>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>> >>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>>>> >>>>>>> In kvm_lapic_reset, I see: >>>>>>> >>>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>>> >>>>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>>>> >>>>>>> if (bsp) { >>>>>>> /* >>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>>>> * processor when local APIC is enabled. >>>>>>> */ >>>>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>>>> } >>>>>>> >>>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>>>> why does QEMU or KVM enable it? >>>>>>> >>>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>>>> problems in certain cases. >>>>>> >>>>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>>>> more information in the git logs of both code bases? Or something that >>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>>>> Thanks. I found no indication of such thing. >>>>> >>>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>>>> >>>>> Don't route PIC interrupts through the local APIC if the local APIC >>>>> config says so. By Ari Kivity. >>>>> >>>>> Maybe Avi Kivity knows this guy. >>>> >>>> ths? That should have been Thiemo Seufer (IIRC), but he just committed >>>> the code back then (and is no longer with us, sadly). >>> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke >>> about Avi knowing “Ari”). >> >> Ah. No problem. My brain apparently fixed that typo up unnoticed. >> >>>> But if that commit went in without any BIOS changes around it, QEMU >>>> simply had to do the job of the latter to keep things working. >>> So should I leave it as is? Can I at least disable in KVM during INIT (and >>> leave it as is for RESET)? >> >> No, I don't think there is a need to leave this inaccurate for QEMU if >> our included BIOS gets it right. I don't know what the backward >> bug-compatibility of KVM is, though. Maybe you can identify since when >> our BIOS is fine so that we can discuss time frames. > > I think that it was addressed in commit > 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the > local APIC of the BSP.”) So it should be included in seabios 0.5.0, which > means qemu 0.12 - so we are talking about the end of 2009 or start of 2010. The probability that someone will use a newer version of kernel with something as old as 0.12 is probably minimal. I think it's ok to change it with a comment indicating the reason. To be on the safe side, however, a user changeable switch is something worth considering. > What is the verdict? > > Nadav-- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-08 22:11 ` Bandan Das @ 2015-04-09 18:21 ` Nadav Amit 2015-04-09 18:28 ` Avi Kivity 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-09 18:21 UTC (permalink / raw) To: Bandan Das; +Cc: Jan Kiszka, Paolo Bonzini, Avi Kivity, kvm list Bandan Das <bsd@redhat.com> wrote: > Nadav Amit <nadav.amit@gmail.com> writes: > >> Jan Kiszka <jan.kiszka@siemens.com> wrote: >> >>> On 2015-04-08 19:40, Nadav Amit wrote: >>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>> >>>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>>> >>>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>>>>> >>>>>>>> In kvm_lapic_reset, I see: >>>>>>>> >>>>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>>>> >>>>>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>>>>> >>>>>>>> if (bsp) { >>>>>>>> /* >>>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>>>>> * processor when local APIC is enabled. >>>>>>>> */ >>>>>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>>>>> } >>>>>>>> >>>>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>>>>> why does QEMU or KVM enable it? >>>>>>>> >>>>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>>>>> problems in certain cases. >>>>>>> >>>>>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>>>>> more information in the git logs of both code bases? Or something that >>>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>>>>> Thanks. I found no indication of such thing. >>>>>> >>>>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>>>>> >>>>>> Don't route PIC interrupts through the local APIC if the local APIC >>>>>> config says so. By Ari Kivity. >>>>>> >>>>>> Maybe Avi Kivity knows this guy. >>>>> >>>>> ths? That should have been Thiemo Seufer (IIRC), but he just committed >>>>> the code back then (and is no longer with us, sadly). >>>> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke >>>> about Avi knowing “Ari”). >>> >>> Ah. No problem. My brain apparently fixed that typo up unnoticed. >>> >>>>> But if that commit went in without any BIOS changes around it, QEMU >>>>> simply had to do the job of the latter to keep things working. >>>> So should I leave it as is? Can I at least disable in KVM during INIT (and >>>> leave it as is for RESET)? >>> >>> No, I don't think there is a need to leave this inaccurate for QEMU if >>> our included BIOS gets it right. I don't know what the backward >>> bug-compatibility of KVM is, though. Maybe you can identify since when >>> our BIOS is fine so that we can discuss time frames. >> >> I think that it was addressed in commit >> 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the >> local APIC of the BSP.”) So it should be included in seabios 0.5.0, which >> means qemu 0.12 - so we are talking about the end of 2009 or start of 2010. > > The probability that someone will use a newer version of kernel with something > as old as 0.12 is probably minimal. I think it's ok to change it with a comment > indicating the reason. To be on the safe side, however, a user changeable switch > is something worth considering. I don’t see any existing mechanism for KVM to be aware of its user type and version. I do see another case of KVM hacks that are intended for fixing very old QEMU bugs (see 3a624e29c75 changes in vmx_set_segment, which are from pretty much the same time-frame of the issue I try to fix). Since this is something which would follow around, please advise what would be the format. A new ioctl that would supply the userspace “type” (according to predefined constants) and version? Thanks, Nadav ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-09 18:21 ` Nadav Amit @ 2015-04-09 18:28 ` Avi Kivity 2015-04-09 18:49 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Avi Kivity @ 2015-04-09 18:28 UTC (permalink / raw) To: Nadav Amit, Bandan Das; +Cc: Jan Kiszka, Paolo Bonzini, kvm list On 04/09/2015 09:21 PM, Nadav Amit wrote: > Bandan Das <bsd@redhat.com> wrote: > >> Nadav Amit <nadav.amit@gmail.com> writes: >> >>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> >>>> On 2015-04-08 19:40, Nadav Amit wrote: >>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>> >>>>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>>>> >>>>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>>>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>>>>>> >>>>>>>>> In kvm_lapic_reset, I see: >>>>>>>>> >>>>>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>>>>> >>>>>>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>>>>>> >>>>>>>>> if (bsp) { >>>>>>>>> /* >>>>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>>>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>>>>>> * processor when local APIC is enabled. >>>>>>>>> */ >>>>>>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>>>>>> why does QEMU or KVM enable it? >>>>>>>>> >>>>>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>>>>>> problems in certain cases. >>>>>>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>>>>>> more information in the git logs of both code bases? Or something that >>>>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>>>>>> Thanks. I found no indication of such thing. >>>>>>> >>>>>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>>>>>> >>>>>>> Don't route PIC interrupts through the local APIC if the local APIC >>>>>>> config says so. By Ari Kivity. >>>>>>> >>>>>>> Maybe Avi Kivity knows this guy. >>>>>> ths? That should have been Thiemo Seufer (IIRC), but he just committed >>>>>> the code back then (and is no longer with us, sadly). >>>>> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke >>>>> about Avi knowing “Ari”). >>>> Ah. No problem. My brain apparently fixed that typo up unnoticed. >>>> >>>>>> But if that commit went in without any BIOS changes around it, QEMU >>>>>> simply had to do the job of the latter to keep things working. >>>>> So should I leave it as is? Can I at least disable in KVM during INIT (and >>>>> leave it as is for RESET)? >>>> No, I don't think there is a need to leave this inaccurate for QEMU if >>>> our included BIOS gets it right. I don't know what the backward >>>> bug-compatibility of KVM is, though. Maybe you can identify since when >>>> our BIOS is fine so that we can discuss time frames. >>> I think that it was addressed in commit >>> 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the >>> local APIC of the BSP.”) So it should be included in seabios 0.5.0, which >>> means qemu 0.12 - so we are talking about the end of 2009 or start of 2010. >> The probability that someone will use a newer version of kernel with something >> as old as 0.12 is probably minimal. I think it's ok to change it with a comment >> indicating the reason. To be on the safe side, however, a user changeable switch >> is something worth considering. > I don’t see any existing mechanism for KVM to be aware of its user type and > version. I do see another case of KVM hacks that are intended for fixing > very old QEMU bugs (see 3a624e29c75 changes in vmx_set_segment, which are > from pretty much the same time-frame of the issue I try to fix). > > Since this is something which would follow around, please advise what would > be the format. A new ioctl that would supply the userspace “type” (according > to predefined constants) and version? That would be madness. KVM shouldn't even know that qemu exists, let alone track its versions. Simply add a new toggle KVM_USE_STANDARD_LAPIC_LVT_INIT and document that userspace MUST use it. Old userspace won't, and will get the old buggy behavior. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-09 18:28 ` Avi Kivity @ 2015-04-09 18:49 ` Nadav Amit 2015-04-09 19:17 ` Bandan Das 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-09 18:49 UTC (permalink / raw) To: Avi Kivity; +Cc: Bandan Das, Jan Kiszka, Paolo Bonzini, kvm list Avi Kivity <avi.kivity@gmail.com> wrote: > On 04/09/2015 09:21 PM, Nadav Amit wrote: >> Bandan Das <bsd@redhat.com> wrote: >> >>> Nadav Amit <nadav.amit@gmail.com> writes: >>> >>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>> >>>>> On 2015-04-08 19:40, Nadav Amit wrote: >>>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>>> >>>>>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>>>>> >>>>>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>>>>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>>>>>>> >>>>>>>>>> In kvm_lapic_reset, I see: >>>>>>>>>> >>>>>>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>>>>>> >>>>>>>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>>>>>>> >>>>>>>>>> if (bsp) { >>>>>>>>>> /* >>>>>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>>>>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>>>>>>> * processor when local APIC is enabled. >>>>>>>>>> */ >>>>>>>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>>>>>>> why does QEMU or KVM enable it? >>>>>>>>>> >>>>>>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>>>>>>> problems in certain cases. >>>>>>>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>>>>>>> more information in the git logs of both code bases? Or something that >>>>>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>>>>>>> Thanks. I found no indication of such thing. >>>>>>>> >>>>>>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>>>>>>> >>>>>>>> Don't route PIC interrupts through the local APIC if the local APIC >>>>>>>> config says so. By Ari Kivity. >>>>>>>> >>>>>>>> Maybe Avi Kivity knows this guy. >>>>>>> ths? That should have been Thiemo Seufer (IIRC), but he just committed >>>>>>> the code back then (and is no longer with us, sadly). >>>>>> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke >>>>>> about Avi knowing “Ari”). >>>>> Ah. No problem. My brain apparently fixed that typo up unnoticed. >>>>> >>>>>>> But if that commit went in without any BIOS changes around it, QEMU >>>>>>> simply had to do the job of the latter to keep things working. >>>>>> So should I leave it as is? Can I at least disable in KVM during INIT (and >>>>>> leave it as is for RESET)? >>>>> No, I don't think there is a need to leave this inaccurate for QEMU if >>>>> our included BIOS gets it right. I don't know what the backward >>>>> bug-compatibility of KVM is, though. Maybe you can identify since when >>>>> our BIOS is fine so that we can discuss time frames. >>>> I think that it was addressed in commit >>>> 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the >>>> local APIC of the BSP.”) So it should be included in seabios 0.5.0, which >>>> means qemu 0.12 - so we are talking about the end of 2009 or start of 2010. >>> The probability that someone will use a newer version of kernel with something >>> as old as 0.12 is probably minimal. I think it's ok to change it with a comment >>> indicating the reason. To be on the safe side, however, a user changeable switch >>> is something worth considering. >> I don’t see any existing mechanism for KVM to be aware of its user type and >> version. I do see another case of KVM hacks that are intended for fixing >> very old QEMU bugs (see 3a624e29c75 changes in vmx_set_segment, which are >> from pretty much the same time-frame of the issue I try to fix). >> >> Since this is something which would follow around, please advise what would >> be the format. A new ioctl that would supply the userspace “type” (according >> to predefined constants) and version? > > That would be madness. KVM shouldn't even know that qemu exists, let alone > track its versions. > > Simply add a new toggle KVM_USE_STANDARD_LAPIC_LVT_INIT and document that > userspace MUST use it. Old userspace won't, and will get the old buggy > behavior. I fully agree it would be madness. Yet it appears to be a recurring problem. Here are similar problems found from a short search: 1. vmx_set_segment setting segment accessed (3a624e29c75) 2. svm_set_cr0 clearing CD and NW (709ddebf81c) 3. Limited number of MTRRs due to Seabios bus (0d234daf7e0a) Excluding (1) all of the other issues are related to the VM BIOS. Perhaps KVM should somehow realize which VM BIOS runs? (yes, it sounds just as bad.) Nadav ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-09 18:49 ` Nadav Amit @ 2015-04-09 19:17 ` Bandan Das 2015-04-10 9:12 ` Paolo Bonzini 0 siblings, 1 reply; 17+ messages in thread From: Bandan Das @ 2015-04-09 19:17 UTC (permalink / raw) To: Nadav Amit; +Cc: Avi Kivity, Jan Kiszka, Paolo Bonzini, kvm list Nadav Amit <nadav.amit@gmail.com> writes: > Avi Kivity <avi.kivity@gmail.com> wrote: > >> On 04/09/2015 09:21 PM, Nadav Amit wrote: >>> Bandan Das <bsd@redhat.com> wrote: >>> >>>> Nadav Amit <nadav.amit@gmail.com> writes: >>>> >>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>> >>>>>> On 2015-04-08 19:40, Nadav Amit wrote: >>>>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>>>> >>>>>>>> On 2015-04-08 18:59, Nadav Amit wrote: >>>>>>>>> Jan Kiszka <jan.kiszka@siemens.com> wrote: >>>>>>>>> >>>>>>>>>> On 2015-04-08 18:40, Nadav Amit wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I would appreciate if someone explains the reason for enabling LINT0 during >>>>>>>>>>> APIC reset. This does not correspond with Intel SDM Figure 10-8: “Local >>>>>>>>>>> Vector Table” that says all LVT registers are reset to 0x10000. >>>>>>>>>>> >>>>>>>>>>> In kvm_lapic_reset, I see: >>>>>>>>>>> >>>>>>>>>>> apic_set_reg(apic, APIC_LVT0, >>>>>>>>>>> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >>>>>>>>>>> >>>>>>>>>>> Which is actually pretty similar to QEMU’s apic_reset_common: >>>>>>>>>>> >>>>>>>>>>> if (bsp) { >>>>>>>>>>> /* >>>>>>>>>>> * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization >>>>>>>>>>> * time typically by BIOS, so PIC interrupt can be delivered to the >>>>>>>>>>> * processor when local APIC is enabled. >>>>>>>>>>> */ >>>>>>>>>>> s->lvt[APIC_LVT_LINT0] = 0x700; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Yet, in both cases, I miss the point - if it is typically done by the BIOS, >>>>>>>>>>> why does QEMU or KVM enable it? >>>>>>>>>>> >>>>>>>>>>> BTW: KVM seems to run fine without it, and I think setting it causes me >>>>>>>>>>> problems in certain cases. >>>>>>>>>> I suspect it has some historic BIOS backgrounds. Already tried to find >>>>>>>>>> more information in the git logs of both code bases? Or something that >>>>>>>>>> indicates of SeaBIOS or BochsBIOS once didn't do this initialization? >>>>>>>>> Thanks. I found no indication of such thing. >>>>>>>>> >>>>>>>>> QEMU’s commit message (0e21e12bb311c4c1095d0269dc2ef81196ccb60a) says: >>>>>>>>> >>>>>>>>> Don't route PIC interrupts through the local APIC if the local APIC >>>>>>>>> config says so. By Ari Kivity. >>>>>>>>> >>>>>>>>> Maybe Avi Kivity knows this guy. >>>>>>>> ths? That should have been Thiemo Seufer (IIRC), but he just committed >>>>>>>> the code back then (and is no longer with us, sadly). >>>>>>> Oh… I am sorry - I didn’t know about that.. (I tried to make an unfunny joke >>>>>>> about Avi knowing “Ari”). >>>>>> Ah. No problem. My brain apparently fixed that typo up unnoticed. >>>>>> >>>>>>>> But if that commit went in without any BIOS changes around it, QEMU >>>>>>>> simply had to do the job of the latter to keep things working. >>>>>>> So should I leave it as is? Can I at least disable in KVM during INIT (and >>>>>>> leave it as is for RESET)? >>>>>> No, I don't think there is a need to leave this inaccurate for QEMU if >>>>>> our included BIOS gets it right. I don't know what the backward >>>>>> bug-compatibility of KVM is, though. Maybe you can identify since when >>>>>> our BIOS is fine so that we can discuss time frames. >>>>> I think that it was addressed in commit >>>>> 19c1a7692bf65fc40e56f93ad00cc3eefaad22a4 ("Initialize the LINT LVTs on the >>>>> local APIC of the BSP.”) So it should be included in seabios 0.5.0, which >>>>> means qemu 0.12 - so we are talking about the end of 2009 or start of 2010. >>>> The probability that someone will use a newer version of kernel with something >>>> as old as 0.12 is probably minimal. I think it's ok to change it with a comment >>>> indicating the reason. To be on the safe side, however, a user changeable switch >>>> is something worth considering. >>> I don’t see any existing mechanism for KVM to be aware of its user type and >>> version. I do see another case of KVM hacks that are intended for fixing >>> very old QEMU bugs (see 3a624e29c75 changes in vmx_set_segment, which are >>> from pretty much the same time-frame of the issue I try to fix). >>> >>> Since this is something which would follow around, please advise what would >>> be the format. A new ioctl that would supply the userspace “type” (according >>> to predefined constants) and version? >> >> That would be madness. KVM shouldn't even know that qemu exists, let alone >> track its versions. >> >> Simply add a new toggle KVM_USE_STANDARD_LAPIC_LVT_INIT and document that >> userspace MUST use it. Old userspace won't, and will get the old buggy >> behavior. > > I fully agree it would be madness. Yet it appears to be a recurring problem. > Here are similar problems found from a short search: > > 1. vmx_set_segment setting segment accessed (3a624e29c75) > 2. svm_set_cr0 clearing CD and NW (709ddebf81c) > 3. Limited number of MTRRs due to Seabios bus (0d234daf7e0a) > > Excluding (1) all of the other issues are related to the VM BIOS. Perhaps > KVM should somehow realize which VM BIOS runs? (yes, it sounds just as bad.) How about renaming the toggle Avi mentioned above to something more generic (KVM_DISABLE_LEGACY_QUIRKS ?) and grouping all the issues together ? Modern userspace will always enable it and get the new correct behavior. When more cases are discovered, KVM can just add them to the list. > Nadav > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-09 19:17 ` Bandan Das @ 2015-04-10 9:12 ` Paolo Bonzini 2015-04-12 18:29 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Paolo Bonzini @ 2015-04-10 9:12 UTC (permalink / raw) To: Bandan Das, Nadav Amit; +Cc: Avi Kivity, Jan Kiszka, kvm list On 09/04/2015 21:17, Bandan Das wrote: > > Excluding (1) all of the other issues are related to the VM BIOS. Perhaps > > KVM should somehow realize which VM BIOS runs? (yes, it sounds just as bad.) > > How about renaming the toggle Avi mentioned above to something more generic > (KVM_DISABLE_LEGACY_QUIRKS ?) and grouping all the issues together ? Modern userspace > will always enable it and get the new correct behavior. When more cases are discovered, > KVM can just add them to the list. It can be a VM capability (KVM_FIRMWARE_QUIRKS?) that is enabled via KVM_ENABLE_CAP. The first argument in struct kvm_enable_cap can be used to add more quirks in the future. For now, an argument of zero could be used to: 1) set up LINT0 correctly 2) set up CD and NW correctly in svm_set_cr0 AFAIK the MTRR issue in SeaBIOS was not fixed. For that, QEMU could write to MSR_MTRRcap with KVM_SET_MSR. Setting the "accessed" bit in vmx_set_segment is IMHO harmless, and we might as well do it even if !enable_unrestricted_guest. Paolo ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: x86: Question regarding the reset value of LINT0 2015-04-10 9:12 ` Paolo Bonzini @ 2015-04-12 18:29 ` Nadav Amit 2015-04-12 22:53 ` [PATCH] KVM: x86: Support for disabling quirks Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-12 18:29 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Bandan Das, Avi Kivity, Jan Kiszka, kvm list Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 09/04/2015 21:17, Bandan Das wrote: >>> Excluding (1) all of the other issues are related to the VM BIOS. Perhaps >>> KVM should somehow realize which VM BIOS runs? (yes, it sounds just as bad.) >> >> How about renaming the toggle Avi mentioned above to something more generic >> (KVM_DISABLE_LEGACY_QUIRKS ?) and grouping all the issues together ? Modern userspace >> will always enable it and get the new correct behavior. When more cases are discovered, >> KVM can just add them to the list. > > It can be a VM capability (KVM_FIRMWARE_QUIRKS?) that is enabled via > KVM_ENABLE_CAP. > > The first argument in struct kvm_enable_cap can be used to add more > quirks in the future. For now, an argument of zero could be used to: > > 1) set up LINT0 correctly > > 2) set up CD and NW correctly in svm_set_cr0 > > AFAIK the MTRR issue in SeaBIOS was not fixed. For that, QEMU could > write to MSR_MTRRcap with KVM_SET_MSR. > > Setting the "accessed" bit in vmx_set_segment is IMHO harmless, and we > might as well do it even if !enable_unrestricted_guest. Ok. I’ll send an updated version (as well as updated version of the init/reset issues) in the next few days. Nadav ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] KVM: x86: Support for disabling quirks 2015-04-12 18:29 ` Nadav Amit @ 2015-04-12 22:53 ` Nadav Amit 2015-04-13 10:34 ` Paolo Bonzini 0 siblings, 1 reply; 17+ messages in thread From: Nadav Amit @ 2015-04-12 22:53 UTC (permalink / raw) To: pbonzini; +Cc: kvm, jan.kiszka, bsd, avi.kivity, Nadav Amit Introducing KVM_CAP_DISABLE_QUIRKS for disabling x86 quirks that were previous created in order to overcome QEMU issues. Those issue were mostly result of invalid VM BIOS. Currently there are two quirks that can be disabled: 1. KVM_QUIRK_LINT0_REENABLED - LINT0 was enabled after boot 2. KVM_QUIRK_CD_NW_CLEARED - CD and NW are cleared after boot These two issues are already resolved in recent releases of QEMU, and would therefore be disabled by QEMU. Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> --- Documentation/virtual/kvm/api.txt | 3 ++- arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/include/uapi/asm/kvm.h | 3 +++ arch/x86/kvm/lapic.c | 5 +++-- arch/x86/kvm/svm.c | 3 ++- arch/x86/kvm/x86.c | 29 +++++++++++++++++++++++++++++ include/uapi/linux/kvm.h | 1 + 7 files changed, 42 insertions(+), 4 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index bc9f6fe..3931221 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -959,7 +959,8 @@ documentation when it pops into existence). 4.37 KVM_ENABLE_CAP Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM -Architectures: ppc, s390 +Architectures: x86 (only KVM_CAP_ENABLE_CAP_VM), + mips (only KVM_CAP_ENABLE_CAP), ppc, s390 Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM) Parameters: struct kvm_enable_cap (in) Returns: 0 on success; -1 on error diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index dea2e7e..f80ad59 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -635,6 +635,8 @@ struct kvm_arch { #endif bool boot_vcpu_runs_old_kvmclock; + + u64 disabled_quirks; }; struct kvm_vm_stat { diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h index d7dcef5..2fec75e 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -345,4 +345,7 @@ struct kvm_xcrs { struct kvm_sync_regs { }; +#define KVM_QUIRK_LINT0_REENABLED (1 << 0) +#define KVM_QUIRK_CD_NW_CLEARED (1 << 1) + #endif /* _ASM_X86_KVM_H */ diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 4a6e58a..fe2d89e 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -1577,8 +1577,9 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu) for (i = 0; i < APIC_LVT_NUM; i++) apic_set_reg(apic, APIC_LVTT + 0x10 * i, APIC_LVT_MASKED); apic->lapic_timer.timer_mode = 0; - apic_set_reg(apic, APIC_LVT0, - SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); + if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_LINT0_REENABLED)) + apic_set_reg(apic, APIC_LVT0, + SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); apic_set_reg(apic, APIC_DFR, 0xffffffffU); apic_set_spiv(apic, 0xff); diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index ce741b8..46299da 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -1575,7 +1575,8 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) * does not do it - this results in some delay at * reboot */ - cr0 &= ~(X86_CR0_CD | X86_CR0_NW); + if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED)) + cr0 &= ~(X86_CR0_CD | X86_CR0_NW); svm->vmcb->save.cr0 = cr0; mark_dirty(svm->vmcb, VMCB_CR); update_cr0_intercept(svm); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b8cb1d0..c3859a6 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2778,6 +2778,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_HYPERV_TIME: case KVM_CAP_IOAPIC_POLARITY_IGNORED: case KVM_CAP_TSC_DEADLINE_TIMER: + case KVM_CAP_ENABLE_CAP_VM: #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_ASSIGN_DEV_IRQ: case KVM_CAP_PCI_2_3: @@ -3825,6 +3826,26 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_event, return 0; } +static int kvm_vm_ioctl_enable_cap(struct kvm *kvm, + struct kvm_enable_cap *cap) +{ + int r; + + if (cap->flags) + return -EINVAL; + + switch (cap->cap) { + case KVM_CAP_DISABLE_QUIRKS: + kvm->arch.disabled_quirks = cap->args[0]; + r = 0; + break; + default: + r = -EINVAL; + break; + } + return r; +} + long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg) { @@ -4077,7 +4098,15 @@ long kvm_arch_vm_ioctl(struct file *filp, r = 0; break; } + case KVM_ENABLE_CAP: { + struct kvm_enable_cap cap; + r = -EFAULT; + if (copy_from_user(&cap, argp, sizeof(cap))) + goto out; + r = kvm_vm_ioctl_enable_cap(kvm, &cap); + break; + } default: r = kvm_vm_ioctl_assigned_device(kvm, ioctl, arg); } diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index f574d7b..01c0a8e 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -813,6 +813,7 @@ struct kvm_ppc_smmu_info { #define KVM_CAP_MIPS_MSA 112 #define KVM_CAP_S390_INJECT_IRQ 113 #define KVM_CAP_S390_IRQ_STATE 114 +#define KVM_CAP_DISABLE_QUIRKS 115 #ifdef KVM_CAP_IRQ_ROUTING -- 1.9.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] KVM: x86: Support for disabling quirks 2015-04-12 22:53 ` [PATCH] KVM: x86: Support for disabling quirks Nadav Amit @ 2015-04-13 10:34 ` Paolo Bonzini 2015-04-13 12:02 ` Nadav Amit 0 siblings, 1 reply; 17+ messages in thread From: Paolo Bonzini @ 2015-04-13 10:34 UTC (permalink / raw) To: Nadav Amit; +Cc: kvm, jan.kiszka, bsd, avi.kivity On 13/04/2015 00:53, Nadav Amit wrote: > Introducing KVM_CAP_DISABLE_QUIRKS for disabling x86 quirks that were previous > created in order to overcome QEMU issues. Those issue were mostly result of > invalid VM BIOS. Currently there are two quirks that can be disabled: > > 1. KVM_QUIRK_LINT0_REENABLED - LINT0 was enabled after boot > 2. KVM_QUIRK_CD_NW_CLEARED - CD and NW are cleared after boot > > These two issues are already resolved in recent releases of QEMU, and would > therefore be disabled by QEMU. > > Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> > --- > Documentation/virtual/kvm/api.txt | 3 ++- > arch/x86/include/asm/kvm_host.h | 2 ++ > arch/x86/include/uapi/asm/kvm.h | 3 +++ > arch/x86/kvm/lapic.c | 5 +++-- > arch/x86/kvm/svm.c | 3 ++- > arch/x86/kvm/x86.c | 29 +++++++++++++++++++++++++++++ > include/uapi/linux/kvm.h | 1 + > 7 files changed, 42 insertions(+), 4 deletions(-) > > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index bc9f6fe..3931221 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -959,7 +959,8 @@ documentation when it pops into existence). > 4.37 KVM_ENABLE_CAP > > Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM > -Architectures: ppc, s390 > +Architectures: x86 (only KVM_CAP_ENABLE_CAP_VM), > + mips (only KVM_CAP_ENABLE_CAP), ppc, s390 > Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM) > Parameters: struct kvm_enable_cap (in) > Returns: 0 on success; -1 on error > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index dea2e7e..f80ad59 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -635,6 +635,8 @@ struct kvm_arch { > #endif > > bool boot_vcpu_runs_old_kvmclock; > + > + u64 disabled_quirks; > }; > > struct kvm_vm_stat { > diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h > index d7dcef5..2fec75e 100644 > --- a/arch/x86/include/uapi/asm/kvm.h > +++ b/arch/x86/include/uapi/asm/kvm.h > @@ -345,4 +345,7 @@ struct kvm_xcrs { > struct kvm_sync_regs { > }; > > +#define KVM_QUIRK_LINT0_REENABLED (1 << 0) > +#define KVM_QUIRK_CD_NW_CLEARED (1 << 1) > + > #endif /* _ASM_X86_KVM_H */ > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > index 4a6e58a..fe2d89e 100644 > --- a/arch/x86/kvm/lapic.c > +++ b/arch/x86/kvm/lapic.c > @@ -1577,8 +1577,9 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu) > for (i = 0; i < APIC_LVT_NUM; i++) > apic_set_reg(apic, APIC_LVTT + 0x10 * i, APIC_LVT_MASKED); > apic->lapic_timer.timer_mode = 0; > - apic_set_reg(apic, APIC_LVT0, > - SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); > + if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_LINT0_REENABLED)) > + apic_set_reg(apic, APIC_LVT0, > + SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); > > apic_set_reg(apic, APIC_DFR, 0xffffffffU); > apic_set_spiv(apic, 0xff); > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index ce741b8..46299da 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -1575,7 +1575,8 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) > * does not do it - this results in some delay at > * reboot > */ > - cr0 &= ~(X86_CR0_CD | X86_CR0_NW); > + if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED)) > + cr0 &= ~(X86_CR0_CD | X86_CR0_NW); > svm->vmcb->save.cr0 = cr0; > mark_dirty(svm->vmcb, VMCB_CR); > update_cr0_intercept(svm); > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index b8cb1d0..c3859a6 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -2778,6 +2778,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_HYPERV_TIME: > case KVM_CAP_IOAPIC_POLARITY_IGNORED: > case KVM_CAP_TSC_DEADLINE_TIMER: > + case KVM_CAP_ENABLE_CAP_VM: > #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT > case KVM_CAP_ASSIGN_DEV_IRQ: > case KVM_CAP_PCI_2_3: > @@ -3825,6 +3826,26 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_event, > return 0; > } > > +static int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > + struct kvm_enable_cap *cap) > +{ > + int r; > + > + if (cap->flags) > + return -EINVAL; > + > + switch (cap->cap) { > + case KVM_CAP_DISABLE_QUIRKS: > + kvm->arch.disabled_quirks = cap->args[0]; > + r = 0; > + break; > + default: > + r = -EINVAL; > + break; > + } > + return r; > +} > + > long kvm_arch_vm_ioctl(struct file *filp, > unsigned int ioctl, unsigned long arg) > { > @@ -4077,7 +4098,15 @@ long kvm_arch_vm_ioctl(struct file *filp, > r = 0; > break; > } > + case KVM_ENABLE_CAP: { > + struct kvm_enable_cap cap; > > + r = -EFAULT; > + if (copy_from_user(&cap, argp, sizeof(cap))) > + goto out; > + r = kvm_vm_ioctl_enable_cap(kvm, &cap); > + break; > + } > default: > r = kvm_vm_ioctl_assigned_device(kvm, ioctl, arg); > } > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index f574d7b..01c0a8e 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -813,6 +813,7 @@ struct kvm_ppc_smmu_info { > #define KVM_CAP_MIPS_MSA 112 > #define KVM_CAP_S390_INJECT_IRQ 113 > #define KVM_CAP_S390_IRQ_STATE 114 > +#define KVM_CAP_DISABLE_QUIRKS 115 > > #ifdef KVM_CAP_IRQ_ROUTING > > Applied (locally) for 4.2. Paolo ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] KVM: x86: Support for disabling quirks 2015-04-13 10:34 ` Paolo Bonzini @ 2015-04-13 12:02 ` Nadav Amit 0 siblings, 0 replies; 17+ messages in thread From: Nadav Amit @ 2015-04-13 12:02 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Nadav Amit, kvm list, Jan Kiszka, bsd, avi.kivity Thanks. If you want a test-case you can apply/try the following on top of the previous kvm-unit-tests patch-set I sent ( http://www.spinics.net/lists/kvm/msg115525.html ). Regards, Nadav -- >8 -- From: Nadav Amit <namit@cs.technion.ac.il> Subject: [PATCH kvm-unit-tests] x86: Test LINT0 is disabled after reset Requires x2APIC in order to easily save LINT0 during 16-bit code. For the test to pass a fix for qemu is required. Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> --- x86/init.c | 13 ++++++++++++- x86/unittests.cfg | 1 + 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/x86/init.c b/x86/init.c index 2d7ea99..23079ad 100644 --- a/x86/init.c +++ b/x86/init.c @@ -70,6 +70,7 @@ static struct expected_state expected[] = { #define cr2 (*(volatile int*)0x2010) #define sysenter_eip (*(volatile int*)0x2014) #define boot_apic_id (*(volatile int *)0x2018) +#define lvt0 (*(volatile int *)0x201c) static void set_test_regs(void) { @@ -94,7 +95,10 @@ static bool check_test_regs(bool init) printf("wrong sysenter_eip msr: %x\n", sysenter_eip); error = true; } - + if (lvt0 != 0x10000) { + printf("wrong lvt0 value: %x\n", lvt0); + error = true; + } return error; } @@ -240,6 +244,13 @@ asm ( "cpuid\n" "shrl $24, %ebx\n" "mov %ebx, %cs:0x2018\n" // apic_id + "mov $0x1b, %ecx\n" // IA32_APIC_BASE + "rdmsr\n" + "or $0x400, %eax\n" + "wrmsr\n" // Enabling x2apic + "mov $0x835, %ecx\n" + "rdmsr\n" + "mov %eax, %cs:0x201c\n" // lvt0 "mov $0x0f, %al\n" // rtc_out(0x0f, 0x00); "out %al, $0x70\n" "mov $0x00, %al\n" diff --git a/x86/unittests.cfg b/x86/unittests.cfg index 2d25801..0d1a42b 100644 --- a/x86/unittests.cfg +++ b/x86/unittests.cfg @@ -86,6 +86,7 @@ arch = x86_64 [init] file = init.flat smp = 2 +extra_params = -cpu qemu64,+x2apic [msr] file = msr.flat -- 1.9.1 Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 13/04/2015 00:53, Nadav Amit wrote: >> Introducing KVM_CAP_DISABLE_QUIRKS for disabling x86 quirks that were previous >> created in order to overcome QEMU issues. Those issue were mostly result of >> invalid VM BIOS. Currently there are two quirks that can be disabled: >> >> 1. KVM_QUIRK_LINT0_REENABLED - LINT0 was enabled after boot >> 2. KVM_QUIRK_CD_NW_CLEARED - CD and NW are cleared after boot >> >> These two issues are already resolved in recent releases of QEMU, and would >> therefore be disabled by QEMU. >> >> Signed-off-by: Nadav Amit <namit@cs.technion.ac.il> >> --- >> Documentation/virtual/kvm/api.txt | 3 ++- >> arch/x86/include/asm/kvm_host.h | 2 ++ >> arch/x86/include/uapi/asm/kvm.h | 3 +++ >> arch/x86/kvm/lapic.c | 5 +++-- >> arch/x86/kvm/svm.c | 3 ++- >> arch/x86/kvm/x86.c | 29 +++++++++++++++++++++++++++++ >> include/uapi/linux/kvm.h | 1 + >> 7 files changed, 42 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >> index bc9f6fe..3931221 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -959,7 +959,8 @@ documentation when it pops into existence). >> 4.37 KVM_ENABLE_CAP >> >> Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM >> -Architectures: ppc, s390 >> +Architectures: x86 (only KVM_CAP_ENABLE_CAP_VM), >> + mips (only KVM_CAP_ENABLE_CAP), ppc, s390 >> Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM) >> Parameters: struct kvm_enable_cap (in) >> Returns: 0 on success; -1 on error >> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h >> index dea2e7e..f80ad59 100644 >> --- a/arch/x86/include/asm/kvm_host.h >> +++ b/arch/x86/include/asm/kvm_host.h >> @@ -635,6 +635,8 @@ struct kvm_arch { >> #endif >> >> bool boot_vcpu_runs_old_kvmclock; >> + >> + u64 disabled_quirks; >> }; >> >> struct kvm_vm_stat { >> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h >> index d7dcef5..2fec75e 100644 >> --- a/arch/x86/include/uapi/asm/kvm.h >> +++ b/arch/x86/include/uapi/asm/kvm.h >> @@ -345,4 +345,7 @@ struct kvm_xcrs { >> struct kvm_sync_regs { >> }; >> >> +#define KVM_QUIRK_LINT0_REENABLED (1 << 0) >> +#define KVM_QUIRK_CD_NW_CLEARED (1 << 1) >> + >> #endif /* _ASM_X86_KVM_H */ >> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c >> index 4a6e58a..fe2d89e 100644 >> --- a/arch/x86/kvm/lapic.c >> +++ b/arch/x86/kvm/lapic.c >> @@ -1577,8 +1577,9 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu) >> for (i = 0; i < APIC_LVT_NUM; i++) >> apic_set_reg(apic, APIC_LVTT + 0x10 * i, APIC_LVT_MASKED); >> apic->lapic_timer.timer_mode = 0; >> - apic_set_reg(apic, APIC_LVT0, >> - SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >> + if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_LINT0_REENABLED)) >> + apic_set_reg(apic, APIC_LVT0, >> + SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT)); >> >> apic_set_reg(apic, APIC_DFR, 0xffffffffU); >> apic_set_spiv(apic, 0xff); >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> index ce741b8..46299da 100644 >> --- a/arch/x86/kvm/svm.c >> +++ b/arch/x86/kvm/svm.c >> @@ -1575,7 +1575,8 @@ static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0) >> * does not do it - this results in some delay at >> * reboot >> */ >> - cr0 &= ~(X86_CR0_CD | X86_CR0_NW); >> + if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED)) >> + cr0 &= ~(X86_CR0_CD | X86_CR0_NW); >> svm->vmcb->save.cr0 = cr0; >> mark_dirty(svm->vmcb, VMCB_CR); >> update_cr0_intercept(svm); >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index b8cb1d0..c3859a6 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -2778,6 +2778,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) >> case KVM_CAP_HYPERV_TIME: >> case KVM_CAP_IOAPIC_POLARITY_IGNORED: >> case KVM_CAP_TSC_DEADLINE_TIMER: >> + case KVM_CAP_ENABLE_CAP_VM: >> #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT >> case KVM_CAP_ASSIGN_DEV_IRQ: >> case KVM_CAP_PCI_2_3: >> @@ -3825,6 +3826,26 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_event, >> return 0; >> } >> >> +static int kvm_vm_ioctl_enable_cap(struct kvm *kvm, >> + struct kvm_enable_cap *cap) >> +{ >> + int r; >> + >> + if (cap->flags) >> + return -EINVAL; >> + >> + switch (cap->cap) { >> + case KVM_CAP_DISABLE_QUIRKS: >> + kvm->arch.disabled_quirks = cap->args[0]; >> + r = 0; >> + break; >> + default: >> + r = -EINVAL; >> + break; >> + } >> + return r; >> +} >> + >> long kvm_arch_vm_ioctl(struct file *filp, >> unsigned int ioctl, unsigned long arg) >> { >> @@ -4077,7 +4098,15 @@ long kvm_arch_vm_ioctl(struct file *filp, >> r = 0; >> break; >> } >> + case KVM_ENABLE_CAP: { >> + struct kvm_enable_cap cap; >> >> + r = -EFAULT; >> + if (copy_from_user(&cap, argp, sizeof(cap))) >> + goto out; >> + r = kvm_vm_ioctl_enable_cap(kvm, &cap); >> + break; >> + } >> default: >> r = kvm_vm_ioctl_assigned_device(kvm, ioctl, arg); >> } >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index f574d7b..01c0a8e 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -813,6 +813,7 @@ struct kvm_ppc_smmu_info { >> #define KVM_CAP_MIPS_MSA 112 >> #define KVM_CAP_S390_INJECT_IRQ 113 >> #define KVM_CAP_S390_IRQ_STATE 114 >> +#define KVM_CAP_DISABLE_QUIRKS 115 >> >> #ifdef KVM_CAP_IRQ_ROUTING > > Applied (locally) for 4.2. > > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-04-13 12:02 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-08 16:40 x86: Question regarding the reset value of LINT0 Nadav Amit 2015-04-08 16:44 ` Jan Kiszka 2015-04-08 16:59 ` Nadav Amit 2015-04-08 17:06 ` Jan Kiszka 2015-04-08 17:40 ` Nadav Amit 2015-04-08 17:51 ` Jan Kiszka 2015-04-08 21:49 ` Nadav Amit 2015-04-08 22:11 ` Bandan Das 2015-04-09 18:21 ` Nadav Amit 2015-04-09 18:28 ` Avi Kivity 2015-04-09 18:49 ` Nadav Amit 2015-04-09 19:17 ` Bandan Das 2015-04-10 9:12 ` Paolo Bonzini 2015-04-12 18:29 ` Nadav Amit 2015-04-12 22:53 ` [PATCH] KVM: x86: Support for disabling quirks Nadav Amit 2015-04-13 10:34 ` Paolo Bonzini 2015-04-13 12:02 ` Nadav Amit
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.