4 ms·

> It already supports a number of obscure options (you can make QEMU claim to support a CPU feature regardless of whether the host CPU supports it, really?), so

> It already supports a number of obscure options (you can make QEMU claim to support a CPU feature regardless of whether the host CPU supports it, really?), so adding one more woild fit in just fine. > Nope. “there are no plans to address it further or fix it in an upcoming release”. <https://bugzilla.redhat.com/show_bug.cgi?id=1408810 https://bugzilla.redhat.com/show_bug.cgi?id=1408810> I could see that being the response of an individual open-source developer working for free. But that was IBM saying that, and people pay big bucks to IBM to fix things like this.

Volundr 3y ago
I'm expect if it comes from one of their $X million support contracts their answer will be very different.
- bombcar 3y ago
  You’d like to think so but often even at that level you’re paying for it not to be your fault. Now if your CTO golfs with an exec at IBM, you might get somewhere.
  - qingcharles 3y ago
    Ooo, I gotta start playing golf. That might be the way I can get some support for my Gmail account. "If posting to Hacker News doesn't get your support query fixed, book 9 holes with the board members."
    - matheusmoreira 3y ago
      I really need to get off gmail as soon as possible.
  - worthless-trash 3y ago
    Obvious solution is to get friendly with the package maintainer, find a security vulnerability in the anti-feature you need, lodge security bug, get a CVE, and ask real nicely an upgrade to include the feature^H^H^H^H^H^H^ fix you need. On a serious note, I deal with bug fix / feature requests regularly in Z-Stream (kernel) in an almost weekly cadence, getting the patch upstream, getting the request to backport, making an adequate test of the feature. Source: Worked in product security for little red, now big blue.
  - janosdebugs 3y ago
    At Red Hat, this would usually mostly be a PM+dev+QE decision, not C level. If C level got involved, that meant massive customer impairment. There are simply too many open bugs to spend time on something that no customer is apparently interested in, but if a customer came along with a big burning problem and there was no way for them to architect around it, they'd usually fix something like this. When I worked at Red Hat (virtualization-related, but not libvirt) we had a case where a customer would be running a configuration which was... unwise. We still spent a lot of time figuring out how to help them and shipped a patch that made their life easier. The people working there are not evil, they don't intentionally not fix things, but a bug that is seen as a minor limitation and hasn't popped up in any customer case in 5+ years simply won't get fixed. There hundreds if not thousands of other bugs that are more urgent and only so many developers, QE engineers, docs people to work on this. Even if someone wrote a patch for it, it may not get merged due to how expensive Red Hats process for shipping a change is.
- josephcsible 3y ago
  Having worked for an organization with one of said $X million support contracts with IBM, it often is not.
  - adastra22 3y ago
    What is the point of the support contract then?
    - klodolph 3y ago
      There are a lot of various points to support contracts. Support contracts are not “fix any bug” or “implement any feature”, but… - With a support contract, there are SLAs to respond to incidents / bugs within a timely manner, and - You have a clear escalation path to talk to engineers, rather than customer service, and - While you can’t dictate what features / bugs will get fixed, you do have some weight for prioritization. If you have no support contract, then you may not be able to talk to engineers at all, your bug reports may get completely ignored (not even looked at), etc.
      - adastra22 3y ago
        Yeah but if the response to your bug report is "WONTFIX", it doesn't much matter if you got that reply in a timely manner. It still does you absolutely no good.
        janosdebugs 3y ago
        For Red Hat, there are bugs and there are customer cases. The two are not the same, but they are linked internally. Customer cases don't deal with "X functionality doesn't work in libvirt", but rather a higher level issue that the customer can't resolve due to the underlying bug. Here a workaround the customer can live with is a perfectly acceptable solution. In my time I was there I never saw a bug closed as WONTFIX unless the customer case was resolved in a satisfactory manner. Red Hat people are very aware who's paying the bills. I have seen badly managed escalations, but I've never seen anyone taking customer problems lightly. However, bugs that have no customer case attached to them carry very little weight unless an engineer, a PM, etc says that this is really bad and will cause problems in the future. This is part of where the disconnect comes from. Red Hat prides itself in being an open source company, but it is first and foremost a customer-oriented company. Sure, often individual people will take time they have left and go fix something for the community, but if it's something more involved, it will need PM and management support. Benefiting from and also providing their customers with open source is simply part of the model that has worked for Red Hat, but nobody should be under the illusion that this is done for the greater good. Red Hat is a company and companies serve the purpose of making money for their shareholders. If this happens to align with the interests of the open source community, that's awesome, but will not always be the case. Over the past few years there have been numerous instances of that unfortunate reality. Without knowing the specifics about libvirt's funding, if a project needs to be truly community-driven, the community must come up with a model that doesn't involve Red Hat paying a large portion of the salaries of the people involved, or it will be subject to Red Hat's business interests.
gnufied 3y ago
> . I guess SeaBIOS can't figure out how to assign I/O space to all devices that want some, and so it simply gives up? It appears that although for some devices VM works fine but for others the VM refuses to boot (esp e100) So the answer might be more nuanced than it seems?
- chociej 3y ago
  Those devices for which it works fine are such devices that don't request any I/O space
rwmj 3y ago
It's a bug filed against RHEL 7 originally, by someone working at Red Hat, who suggested that we add the qemu disable-io feature to libvirt. There was no customer case behind either the original RHEL 7 bug nor this cloned RHEL 8 bug, so we simply didn't think it was important to implement this, and 5 years after the original bug was filed, with no customer coming along nor anyone having done the work upstream, the bug was auto-closed. However if someone came along and did the work upstream to fix it, I'm sure that would be accepted. Or if a customer turned up who wanted this, that would also be implemented.
- emmelaich 3y ago
  WONTFIX sounds so final. Though, reading the closing comment, this is really CLOSED-WONTFIXYET, as in no plans. Maybe it'd be nice to introduce a WONTFIXYET. Might be useful to fossick among features abandoned that someday become feasible.
  - Tyr42 3y ago
    We usually use "Open, P4" (0 is highest. 2 is standard) for unscheduled work.
    - emmelaich 3y ago
      Some people strongly dislike "open" for anything not being worked on or having plans to work on. And I've come to agree to that. You just do not want it showing up in backlogs at all.
  - adastra22 3y ago
    Yeah WONTFIX implies will not accept patches in every project I've worked on.
    - broodbucket 3y ago
      Lucky they're not the ones accepting patches. If upstream adopts it they'd have to disable support in their build, which seems unlikely. I wouldn't read WONTFIX like that for anything downstream (i.e. a distribution bug tracker for projects they package). It's we won't do it, not noone else can. WONTFIX only means WONTFIX if that's in the one true source of the project, i.e. upstream. RH usually have a lot of not-upstream patches though (at least they do for the kernel, grub, and qemu, so I assume the same for libvirt) which complicates things a bit.
dark-star 3y ago
Because, if you read the report, suc an option is not needed: - if you disable IO port allocation and plug in a card that requires it, that card cannot possibly work - if you don't disable it but use only cards that don't require IO ports, you might get an error in your dmesg but the card will still work just fine So, why would you need to specify this option in the first place?
wkat4242 3y ago
As redhat becomes more commercial it's imperative we don't let them be stewards of open source anymore. Too many times to their corporate strategy. For example they took ownership of X11 only so they can let it die in favor of their preferred Wayland. While Wayland is not bad, it's not covering everything. But anyway I don't really care anymore, I'm less and less invested in the Linux ecosystem. It's too commercial now, I just stick with the BSDs <3

Volundr 3y ago

I'm expect if it comes from one of their $X million support contracts their answer will be very different.

bombcar 3y ago
You’d like to think so but often even at that level you’re paying for it not to be your fault. Now if your CTO golfs with an exec at IBM, you might get somewhere.
- qingcharles 3y ago
  Ooo, I gotta start playing golf. That might be the way I can get some support for my Gmail account. "If posting to Hacker News doesn't get your support query fixed, book 9 holes with the board members."
  - matheusmoreira 3y ago
    I really need to get off gmail as soon as possible.
- worthless-trash 3y ago
  Obvious solution is to get friendly with the package maintainer, find a security vulnerability in the anti-feature you need, lodge security bug, get a CVE, and ask real nicely an upgrade to include the feature^H^H^H^H^H^H^ fix you need. On a serious note, I deal with bug fix / feature requests regularly in Z-Stream (kernel) in an almost weekly cadence, getting the patch upstream, getting the request to backport, making an adequate test of the feature. Source: Worked in product security for little red, now big blue.
- janosdebugs 3y ago
  At Red Hat, this would usually mostly be a PM+dev+QE decision, not C level. If C level got involved, that meant massive customer impairment. There are simply too many open bugs to spend time on something that no customer is apparently interested in, but if a customer came along with a big burning problem and there was no way for them to architect around it, they'd usually fix something like this. When I worked at Red Hat (virtualization-related, but not libvirt) we had a case where a customer would be running a configuration which was... unwise. We still spent a lot of time figuring out how to help them and shipped a patch that made their life easier. The people working there are not evil, they don't intentionally not fix things, but a bug that is seen as a minor limitation and hasn't popped up in any customer case in 5+ years simply won't get fixed. There hundreds if not thousands of other bugs that are more urgent and only so many developers, QE engineers, docs people to work on this. Even if someone wrote a patch for it, it may not get merged due to how expensive Red Hats process for shipping a change is.
josephcsible 3y ago
Having worked for an organization with one of said $X million support contracts with IBM, it often is not.
- adastra22 3y ago
  What is the point of the support contract then?
  - klodolph 3y ago
    There are a lot of various points to support contracts. Support contracts are not “fix any bug” or “implement any feature”, but… - With a support contract, there are SLAs to respond to incidents / bugs within a timely manner, and - You have a clear escalation path to talk to engineers, rather than customer service, and - While you can’t dictate what features / bugs will get fixed, you do have some weight for prioritization. If you have no support contract, then you may not be able to talk to engineers at all, your bug reports may get completely ignored (not even looked at), etc.
    - adastra22 3y ago
      Yeah but if the response to your bug report is "WONTFIX", it doesn't much matter if you got that reply in a timely manner. It still does you absolutely no good.
      - janosdebugs 3y ago
        For Red Hat, there are bugs and there are customer cases. The two are not the same, but they are linked internally. Customer cases don't deal with "X functionality doesn't work in libvirt", but rather a higher level issue that the customer can't resolve due to the underlying bug. Here a workaround the customer can live with is a perfectly acceptable solution. In my time I was there I never saw a bug closed as WONTFIX unless the customer case was resolved in a satisfactory manner. Red Hat people are very aware who's paying the bills. I have seen badly managed escalations, but I've never seen anyone taking customer problems lightly. However, bugs that have no customer case attached to them carry very little weight unless an engineer, a PM, etc says that this is really bad and will cause problems in the future. This is part of where the disconnect comes from. Red Hat prides itself in being an open source company, but it is first and foremost a customer-oriented company. Sure, often individual people will take time they have left and go fix something for the community, but if it's something more involved, it will need PM and management support. Benefiting from and also providing their customers with open source is simply part of the model that has worked for Red Hat, but nobody should be under the illusion that this is done for the greater good. Red Hat is a company and companies serve the purpose of making money for their shareholders. If this happens to align with the interests of the open source community, that's awesome, but will not always be the case. Over the past few years there have been numerous instances of that unfortunate reality. Without knowing the specifics about libvirt's funding, if a project needs to be truly community-driven, the community must come up with a model that doesn't involve Red Hat paying a large portion of the salaries of the people involved, or it will be subject to Red Hat's business interests.

gnufied 3y ago

> . I guess SeaBIOS can't figure out how to assign I/O space to all devices that want some, and so it simply gives up? It appears that although for some devices VM works fine but for others the VM refuses to boot (esp e100) So the answer might be more nuanced than it seems?

chociej 3y ago
Those devices for which it works fine are such devices that don't request any I/O space

rwmj 3y ago

It's a bug filed against RHEL 7 originally, by someone working at Red Hat, who suggested that we add the qemu disable-io feature to libvirt. There was no customer case behind either the original RHEL 7 bug nor this cloned RHEL 8 bug, so we simply didn't think it was important to implement this, and 5 years after the original bug was filed, with no customer coming along nor anyone having done the work upstream, the bug was auto-closed. However if someone came along and did the work upstream to fix it, I'm sure that would be accepted. Or if a customer turned up who wanted this, that would also be implemented.

emmelaich 3y ago
WONTFIX sounds so final. Though, reading the closing comment, this is really CLOSED-WONTFIXYET, as in no plans. Maybe it'd be nice to introduce a WONTFIXYET. Might be useful to fossick among features abandoned that someday become feasible.
- Tyr42 3y ago
  We usually use "Open, P4" (0 is highest. 2 is standard) for unscheduled work.
  - emmelaich 3y ago
    Some people strongly dislike "open" for anything not being worked on or having plans to work on. And I've come to agree to that. You just do not want it showing up in backlogs at all.
- adastra22 3y ago
  Yeah WONTFIX implies will not accept patches in every project I've worked on.
  - broodbucket 3y ago
    Lucky they're not the ones accepting patches. If upstream adopts it they'd have to disable support in their build, which seems unlikely. I wouldn't read WONTFIX like that for anything downstream (i.e. a distribution bug tracker for projects they package). It's we won't do it, not noone else can. WONTFIX only means WONTFIX if that's in the one true source of the project, i.e. upstream. RH usually have a lot of not-upstream patches though (at least they do for the kernel, grub, and qemu, so I assume the same for libvirt) which complicates things a bit.

dark-star 3y ago

Because, if you read the report, suc an option is not needed: - if you disable IO port allocation and plug in a card that requires it, that card cannot possibly work - if you don't disable it but use only cards that don't require IO ports, you might get an error in your dmesg but the card will still work just fine So, why would you need to specify this option in the first place?

wkat4242 3y ago

As redhat becomes more commercial it's imperative we don't let them be stewards of open source anymore. Too many times to their corporate strategy. For example they took ownership of X11 only so they can let it die in favor of their preferred Wayland. While Wayland is not bad, it's not covering everything. But anyway I don't really care anymore, I'm less and less invested in the Linux ecosystem. It's too commercial now, I just stick with the BSDs <3